Home Page Forums Other Emulator Message Boards Audio Overload Not quite AO, but...

I've ported vio2sf to a very bare-bones Linux commandline app (some here will recognize that it's AOSDK with the serial numbers filed off). This means you can now play 2SF rips on Linux (woo hoo!). It's a sucky user experience but it sounds great. Patches to improve usability or whatnot are welcome. Operation is certified only on little-endian, although it doesn't seem like it would be too bad to make work on BE also in case you want your PS3 to sound like a 66 MHz handheld ;-) License is GPLv2 as inherited from Desume.

Get the goods here.

haha! for once TuneNet had it first!

But hey, great work!

The hell is TuneNet?

ETA: Oh, the Amiga player, gotcha.

Well, technically they were playable earlier with a Wine+Winamp combo. Still, good job!

Few answers before anyone asks (I really, really need to make a Manly FAQ section).

1. Many NDS games use streaming music (sometimes exclusively). This player won't handle them, Windows users can play them with either in_cube (http://hcs64.com/in_cube.html) or VGMStream (http://sourceforge.net/projects/vgmstream). The latter is supposed to be portable to hell and back, so I'm sure someone will have a linux port in a jiffy.

2. Almost all sequenced rips *don't* use orignal game driver. This shouldn't be much of a problem, though there can be minute differences in effect handling between driver versions (similar to, say, Saturn driver or Protracker versions). Also, some games simple don't play well with the driver used (seemingly at random, though I'm 100% sure a song that uses more than 450kB of samples won't play). This won't be fixed in any way unless someone can devise a multigame patcher, similar to Saptapper.

3. Few games (of the top of my head: Animal Crossing, Tetris DS, Metroid Prime: Hunters) use dynamic music, meaning they have two or more songs in one sequence data. Original game driver dynamically silences select channels, something that can't be replicated using current rip methods. Vio2SF has a channel mute option, though this won't help you, as the music driver allocates hardware channels dynamically (meaning if there are three trumpet notes that shouldn't be there, each of them will be played on a different channel). Once again, nothing that I can do about this.

BTW, SpotUP, the Hoot sources you've linked to... elsewhere are severly outdated (like, 7-8 years old). They won't help you much, and no, the current sourcebase is unfortunately available only to Hoot devs.

Why the hell do people do this? What's so hard about ripping the correct driver? Why has "kludge things to hell and back so that they work, even if only barely" become an acceptable practice in the last 6 or 7 years or so in the emulation community? First N64, now it's making its way to audio formats, too? Come on, guys.

Look at it this way - If you'd want to listen to the music from Unreal Tournament game would you waste dozens of hours of your life on hacking the main game exe, looking for song load/select procedures, noping the other, unnecessary threads, yanking at least a few hairs from the resulting frustration...
Or would you rather just play the game sound files in any module player? I mean, the game just uses Impulse Tracker modules, standard format, supported by a slew of players.

Same thing here, really.

Sure, the game music driver might have some effect commands supported a bit differently, but really, does this matter this much (given that sound has usually the lowest priority when it comes to CPU utilization, so the files are deliberately kept simple and that the modules themselves weren't made with the game driver but with a tracker which would had the same specs as the *good* standalone players)? We're past the 8-bit systems, the game developers started using middleware and standard libraries ages ago. This is especially noticable on DS - roughly 90% of the games use the same sound code.

Sure, I'd prefer to use original driver in all cases, but I really don't see anyone volunteering to do the hacking work required.

The funny thing is that kludging is *not* acceptable outside of hcs/UF's rip formats, and I daresay it's even lost some popularity for N64 emulation. The stock driver, like sound drivers throughout time, is a standalone piece of code. Once you find it's init, load/select, play, and service-per-frame routines you can just write a self-booting rip that will continue to work for reasonable future versions of the driver, as was done with GSF. USF should have been done that way (although at least there it's somewhat understandable why it wasn't), and 2SF definitely should have.

Uhh, roughly 80% of PSF rips use generic drivers (Mark Grass, davironica's, Neill PSF2 rip kit doesn't really count) as well, you know. At least a quarter of SSF rips don't use the original driver as well.

Unknownfile said that a 2SF mass patcher isn't really doable (due to exe encryption and what not). Finding load/play addreses and patching the rest of the code might be easy for you guys, heck I should be able to do that given a few weeks of training... But during those few weeks I could do, dunno, 100 or so generic rips.

I'm not stoping anyone wanting to do them the 'proper' way, in fact I'll welcome them with open arms.

I was more referring to SSF / 2SF. Regarding USF, I was to understand that each game uses the appropriate sound driver, and it's only a hack in the same way that an NSF or GBS dump is a hack: It's a cut-down version of the ROM (or in USF's case, a saved state) such that only the audio-playback code is still active.

[Remainder axed. This is why we can't have nice things - RB]

That's quite enough children. I've deleted the flame war that just popped up, and I'm going to have a less than zero tolerance for attempts to bring it back up.

K: my understanding is that most current PSF1s are *not* generic driver, or were re-ripped to no longer use one (e.g. Castlevania was a generic driver and missing reverb originally, but the new rips use the correct one). One of the archives used to indicate generic rips and they were always marked for re-ripping.

For PSF2s there's no reason not to use the original driver in games that use the Sony driver since it's always a separate .IRX file on the disc. And of course custom-driver games are always using the correct one.

SSFs largely are using the correct driver unless there's been a great flood of poor quality non-kingshriek rips that nobody told me about.

I stand corrected. What about USF, though? Like I said, I was under the impression it uses the correct driver for each game, ripped from the ROM itself.

Yes, USFs by definition use the correct driver. There would be no Rare rips otherwise.

But they are, really. Even Corlett reused drivers from time to time (Final Fantasy 2 from Origins uses FFIX driver IIRC).
You must've missed that great flood of Japanese contributions, all using davironica/Mark Grass generic drivers or Tactics Ogre/Suikoden 2/Wild Arms 2 drivers. Current PSF/2 rip count stands at 500, I'd say less then 150 (you know, the game more then two people not from Japan care about) use original drivers.


Even some kingshriek rips use incorrect driver (as stated in the comment field). Marica: Shinjitsu no Sekai, Soukyugurentai, Virus. Many Japanese rips use different drivers as well. Not as much as with PSF, but that's largly due to outstanding ripping tools kingshriek provided.

great sounding player, how to export 2sf files to an audio format, or teach Amarok to use them?

vio2sf as a Xine plugin? Interesting idea. Why not convert all AO playing engines to GStreamer or Xine plugins? Linux nerds will love it

About the generic driver discussion: A few years ago when CaitSith2 was still actively involved in PSF stuff (at least, I don't see him anywhere, anymore), he had included that info in his PSF archives. Anyway, who cares if it's the original driver or not, as long as it sounds right. If there's a real audiophile out there, he/she will re-rip the game. Anyone else won't hear the difference. Some other games will probably even require such a generic driver (Tri-Ace PS2 games), because even PCSX2 hasn't managed to run their executables, yet. However, I still doubt that Star Ocean 3 et al even use sequenced music.

EDIT: Mods, delete this last paragraph, if you like.

I've been thinking of that because:

a) I'd certainly love to include *SF in my Amarok playlists

b) Songbird is planning on switching to GStreamer as the backend on all platforms, which gives a multi-player multi-platform story (especially since Amarok is also coming to Windows/Mac and will almost certainly use GStreamer there too)

As far as the rest, audiophile or not I like to know that rips are playing identically to how their actual game does, which is the point. That's why I appreciated it back when CaitSith2 used to re-rip PSFs using the correct driver.

a) i've always wondered how you guys listen to vgm & chiptunes on Linux - on windos, you get plugins for Foobar2000, tune each to make its format sound the way you like it and mix chiptunes with audio in the playlist - on Linux it's not so straightforward: some players like Xmms & Audacious can play chiptunes but have incredibly intolerable interface or playlist, others like Amarok look nice but play almost no chiptunes, those few that work sound really bad and don't have any options to tune them. Using various CLI tools, M1 and AO to make WAVs seems like the only option, but WAVs are final and lack tuning options.

b) if making 2sf & plugins from AO is possible then is it not staightforward to make plugins for both backends at the same time? Amarok used to have GStreamer but some problems occured and now it's focused on Xine

I listen to VGM and chiptunes in AO on Linux, that's sort of the point :-)

I see what you mean about Amarok not using Gstreamer now, that sucks actually. Especially since Gstreamer is the official decoder for KDE4 :-)

i'm sorry but i have great trouble using AO for actual music listening other than cheking out stuff or making WAVs, from the screenshots, it looks like at least Mac version has different interface so maybe it's my KDE that disables certain functionality in AO which leaves me switching tracks manually and pressing Play every time the music stops?

if GStreamer is the official backend of Phonon then Amarok 2 will have no chance and you shouldn't waste time with Xine unless it's easy to do it in parallel

Believe it or not, you're the first person in the history of the project to even hint at what they want the Linux GUI to do. This is why usability is a bit off. Please list the minimal set of changes that would make it usable for you.

ETA: Apparently we've scared you off. I won't get mad, really I always use AO via the debug-only commandline interface (which isn't publically available) so I really have no idea how good the GUI is beyond giving it cool stuff like drag-and-drop.

Regarding GStreamer vs. Xine. Dunno how good GStreamer has become, but everytime I compared, I found Xine the more robust and flexible and compatible backend. After all, it's up to you guys whether or not to use them. But it would really rock if you did

Anyway, I found a pretty interesting discussion in the bsnes forums about how to circumvent GPL rules and stuff. Let the user "opt in". That way the GPL'ed code gets inserted during runtime because of a configuration file modified by the user, not by the developer. Simply ask on first start about whether or not to include some of the problematic drivers (and of course leave the checkboxes blank ). That area seems a little gray, but I think that way you could legally enable AO to make use of your vio2sf port and of course the PEOpS SPU core (I wonder why you never had problems with the GPL status of that one).

Actually many distributions are doing this already - the other way round. Ubuntu with its Restricted Modules packages, for example. The distro may SHIP with them, but the user has to INSTALL them manually.

I have permission from Pete to use the PEOpS cores without following GPL.

I don't think the bsnes methods would stand up in court given that the code would be present in the executable either way. The only reliable way to avoid it is to have a general plugin interface and supply all your engines as plugins (which I think is actually a good idea for AO 2.5 or 3.0 or whatever for several reasons).

I'm not familiar with Ubuntu's specific setup, but for Fedora the "dirty stuff" (ie LAME and other MPEG/MP3 software plus the NV/ATI binary drivers) is actually in a completely separate repository outside of the US that isn't run by anyone from Red Hat, and nothing in the base distro points you to it. That way it's 100% certain it was the user's choice to add it to their yum list :-)

Well, in Ubuntu you gotta enable that repository manually, but it's still maintained by the Masters of the Universe (MOTU). Dunno about the connection to Canonical, though. Still, this repository is present on every mirror.

Oh, and the "really dirty" stuff (e.g. libdvdcss2) is of course not in any official repo.

PS: AO Linux now automatically plays the next song when a song ends, just like the other 2. It's playing through the Parasite Eve OST in the background as I type this

didn't look like my Kubuntu was shipped with them, had to apt-get the restricted stuff, while my Mepis has everything from flash to mp3s working by default - and it's a US distro.

this forum has too many important projects i use frequently to abandon - gaps in discussion can come from totally random stuff and the fact that we're on the opposite sides of Earth.

1) i think the most important thing i would like to see is a way to make WAVs of NSF tracks other than the first one because currently (2.0b10 test 2) neither using "Jump to" or clicking "Next" seem to actually export anything, but they do show "L" (i wrote this into the "test 1" thread too, along with suggestions about looping VGMs)

i think it can be a lot of work to make AO a good general usage player and your skills & time could be put into better use with other projects, because like i posted earlier: imo even "audio players" like Xmms & Audacious fall short in the level of usability of Foobar2000 & Amarok - this is also why we started talking about making the plugins for the backends, to finally allow Linux users to enjoy seamless chiptune action... i had that idea years ago, but i didn't have an account here and also thought if AO hasn't already been made to work from Amarok then there's a reason - didn't know you were using some ultra comfortable CLI debug version and no one else brought it up

trouble is, many chiptune artists like 047 & Phlogiston release their music in audio formats but i love them and like to keep them in the same playlist as chiptune format tracks from artists like Estrayk & Funky Fish along with video game composers.

but my ideas to get better chiptune playing experience from AO:
2) automatic continous playlist repeat & shuffle function that also shuffles inside NSF files
3) ability to set looping or play time for different formats - eg. right now each NSF track plays indefinitely, default time for SPC gives it roughly 2 loops with a fadeout while VGM plays one loop and stops.
4) ability to save & optionally automatically resume playlist playback

these would give us the ability to make nice chiptune playlists, which could get loaded on AO launch and start playing automagically - AO would then shuffle around if the chosen timeframe (or loopcount for certain formats) ends, so it would play without needing maintenance

my x64 2.0b10 test 2 doesn't yet - rechecked just now with Sonic 3 OST in VGM so "test 3" i take?

Now means literally "on my machine", there's not a posted version that does it yet. I'm still working on allowing multiple selections in the File Open box, and I just fixed VGM to take the standard 2 loops instead of 1 + stop.

After looking at the documentation I'm not sure it's possible to do VGM plugins in xine. It's nowhere near as flexible as Gstreamer, and the fact that no VGM-style plugins exist yet isn't a good sign. (Gstreamer has NSF and MikMod plugins in the standard package).

and then onto the next track

would AO plugins for either Xine or GStreamer give you the ability to tune each format, say inside some Amarok settings submenu?

because:
5) more tuning options for AO
imo the best thing about AO is the ability to turn off sound channels & mix away
but there are other ways to interact with chiptunes that's not possible with audio - many Foobar2000 & Winamp plugins have options to tinker with, tho i didn't like how its NSF playback sounded compared to Festalon & AO, NotSo Fatso had nice tuning options; for MOD & XM, XMPlay was also sweet with low pass filters, various tracker playback styles & multichannel mixing - would these be difficult to implement?

AFAIK neither plugin option would give you any tuning ability at all - there's no standard way in either format to expose that sort of thing that I'm aware of.

Adding per-file-format (and possibly per-file-instance) "knobs" is something we're definitely interested in for AO. Those sorts of things are honestly why dedicated VGM players are better for VGM.

Perhaps instead of adding VGM to audio players we should add audio to AO? MP3 at least would be trivial.

sure, i did mean the tuning options mostly for AO, just wondered about their possibility for Linux audio players.

uh oh! the things Amarok does for me atm:
- mp3, ogg vorbis, flac (don't need more than flac because soundKonverter can convert other lossless formats to flac)
- internet radio (eg. http://www.kohina.com/ )
- checks & updates the music collection from my /music folder
- lists the genres of my music collection and allows to load or append them to the playlist (most important imo, depending on the mood, i would load up eg. Eurodance, Chiptunes, Jungle or say House music)
- really really great interface & playlist with easy metadata editing and sorting by it (they changed it into something narrow, horrid & album based for 2.0 but promised to keep the classic one)
- displays a nice announcer overlay every time the track changes (not that important, but nice)
- sys tray & qt (i know it's a tiring subject but apart from Firefox, most progressive apps like even the new VLC use QT instead of GTK - it could also allow you to make one cross platform version together with Mr Bannister, the only problem seems to be that its awesomeness is only free for FOSS projects)

other functions i don't really use, so with these (and maybe M1 too) in AO i wouldn't need any other player in my system and i bet i'm not alone

but that's hella work and i think those 5 features in my previous posts are more urgent than even audio... i wonder, with Amarok being FOSS - couldn't one mix'n'match the features they like into their own projects as long as they keep it FOSS and include the original sauce? They're pretty much dumping the great classic playlist - would be nice if they sourced it separately which you could then comfortably pick up for AO?

This insistence on putting the 12-sided peg of VGM/chiptunes into the square hole of Winamp is exactly why VGM is currently an unsatisfactory experience. People need to understand that VGM/chiptunes are different and need to be handled differently. This "all in one or else" mentality is exactly the opposite of the Unix philosophy (although it explains Windows Vista to a stunning level of detail ;-)

Put another way: you wouldn't use Inkscape for photo touchups and you wouldn't use GIMP to create vector art, even though they're both images. VGM's the same way - it's like vector art, where you *can* turn it into a bitmap (wav/mp3/ogg/flac) but you lose a lot of control and potential flexibility if you do.

I think you're getting a little too harsh here. Of course "normal" music players don't offer as much options as a pure VGM player might, but most people just want a jukebox and nothing more. Sure, multi-track NSF or SID files (hey, I just found another thing AO ought to play one day j/k) are pretty hard to seamlessly integrate into a playlist, but as long as I can put everything into a big 80GB shuffle I don't mind any potential loss of control. Okay, maybe some basic tag reading/editing functionality might be cool - which will probably involve a lot of TagLib hacking...

Somehow I came to like the all-in-one philosphy quite a lot (MAME, Mednafen, Winamp). Vista, however, is more of a too-much-crap-I-don't-need-but-can't-remove-in-one experience - which is one of the reasons why I switched to Linux. Of course the one-app-for-one-task mentality is good in order to keep devs focused when fixing stuff, but you know what the very same people tend to do to vi/Emacs in order to not leave their beloved text editor when browsing or doing their laundry.

hey, you suggested audio first my original 5 suggestions would make AO perfect for chiptunes, at least for me

audio does pave the way for that all in one mentality, even if it materialises in 10 years.

other players are built for audio, chiptunes are an afterthought so it's indeed pushing something big through a hole, but AO has it the other way around - it can perfect chiptunes in a way others can't while casually adding audio one day to make it whole lol.

I actually don't consider MAME or Mednafen to be all-in-one in that same way. There's no equivalent to NSF/SID where the paradigm completely changes.

My understanding of the rules for MP3 support is that one needs a rather expensive license to do, at least officially. Though perhaps it has changed?

Yup, bad example, but I know what you were pointing at.


I didn't quite understand that sentence...

Richard: decoding is free if you aren't charging for the app, but that doesn't clear the patent situation (which is why e.g. Red Hat won't ship anything MPEG). M1's had a decoder for ages for those Sega Digital Sound Board games.

F-3582: multiple songs per game. It's why every attempt to play those formats in Winamp is a giant kludge. There's no equivalent to that in MAME (although MESS has similar issues).

Kay. Well, ideally the plug-in would list all those sub-songs as separate tracks. Which would require some serious pre-processing when adding lots of such files to a playlist... And of course, you would once again need a special tagging format that declared the song length for every single one of them...

would it be possible to display such multi track formats like NSF as separate tracks in the playlist? it sounds natural, yet does any player currently do this? that might open up whole new levels of usability.

imagine someday being able to only include selected NSF tracks in your playlist

Apparently one of the Japanese players has a convention where .KSS files are in a zip with a same-named .M3U and the m3u file "tags" the tracks inside the KSS. I'd like to support that and extend it to NSF - that way the tagged tracks would appear in the playlist.

That would require some core work though. Richard, you game?

Nezplug supports those for all it's formats (NSF/GBS/KSS/HES).
I like XMPlay's SID plugin take on this. Treating the whole song as a single file, showing the subsong info in the info panel, and the ability to skip between subsongs with right-click on the prev/next button.

I've spoken with enough professional UI designers to know that right click should always mean "bring up the context menu" in 2008, but XMPlay's made by democoders so I have no higher expectations for it :-)

Anyway, my concept is that m3u playlisted tracks would behave like archives do now, where the parent node is ignored by the track advance/shuffle but you could click on it manually and use the existing subtrack controls.

Are you sure? I just checked this again, and found:

http://www.mp3licensing.com/royalty/

I remember looking at hooking up LAME to my shareware sound editor for Mac and determined that it wasn't worth doing, as I'd have to jack up the price by 25% for a feature that users could get anyway by encoding with iTunes.

Yes, we went quite in-depth with this a while back for MAME and I've also followed the relevant threads where Redhat legal briefed Fedora. For non-commercial software that decodes only, you're free to go (but if any of the patent holders decides to go after you they can). If you're encoding (ie, LAME) and/or charging for the software you have to pay for the license.

Not sure how your definition of a democoder stands, but only thing Ian Luck and demoscene have in common is one mp3 track released on some netlabel ages ago (well, BASS is used in demos all around, but mainly because it's good, fast and free for noncom use).
Though I'll grant you it's somewhat strange, given that right-clicking on a song gives you a context menu and right-clicking on the main player window brings you skin select menu...
But with XMPLay's expansive shortcuts you don't really need to use the mouse, just pick a key combo you'd like to use and you're good to go.

If you have any connections with those guys, make them post 64-bit versions of BASSMOD :-)

going back to where it started - the 2sf playback - so it's FOSS and not bendable into freeware, but, you could teach AO to use the vio2play executable if, say it finds it in the same folder - AO would then be able to deal with mini2sf files like with any of its native formats

hell Richter, you could also do the same with M1 for great justice since you personally package them all

I'd like to make AO capable of using plugins at some point because a) it means not-us people can make new ones and b) it's a handy dodge around any licensing issues you'd care to name.

Transferring data and commands via a custom, generic, high-level, well-documented stdio interface, perhaps? :3

Mednafen: if you have such an interface in mind, do say more :-)

Meanwhile, I've updated vio2play to the new vio2sf 0.14 code (which is now based on Desmume 0.8 instead of 0.7). Sound quality seems a little better on some sets.

Do you have any examples? I didn't notice anything, but I listen only to a few sets.

Nah, that was completely unscientific listening.

Ah, the best kind!

I got a little sick of dogfooding this as-is and added some improvements: here's vio2play for Linux release 3.

It now behaves roughly like the command-line versions of M1. You can give it multiple 2sf files on the command line (e.g. vio2play *.mini2sf) and use the * and / keys on the keypad to go forward and backwards through the invisible playlist. It also shows the tag info for each song as you bring it up. And you can press Esc or Q to quit cleanly.

There's a new vio2sf and so there's a new vio2play. This one handles Knurek's "every Namco game ever in one file" rip fine.