BML parsing (for playlists)

[ghost]

Any chance of parsing BML files and then using the entries in that as a playlist entry? You could implement BML parsing as a playlist service.

Also, in regards to seeking, I thought the FB2K SDK had examples for an input component, which had seeking.

[qwertymodo]

Manifest parsing would be nice, I was already thinking about it for metadata purposes (using the game name as album title). We'll see if I get around to it, this was a quick evening project, I don't know how much time I'll want to put into really polishing it. Pull requests are always welcome.

Seeking works, it just doesn't do a seek on track end/loop (instead it just continues playing and the seek bar sits at the end). I haven't been able to figure that part out. Every time I try, it throws unhandled exceptions, even if I put it inside a try-catch block. The weird thing is that if I ignore the exceptions and just keep hitting "continue" after a dozen or so, it eventually does seek. However, running it in release mode just causes the whole thing to crash instead. I'm pretty sure it's related to the note in the README about global callbacks only being callable from the main thread, but I have no idea what to do with that information.

[ghost]

I have some experience with the FB2K API (see foo_dsp_effect). Yeah, using metadata from the BML would be cool, but wouldn't that interfere with filename association in general if you want to edit BMLs with your fave editor? Same goes for *.pcm files I guess and they could potentially be associated with other RAW audio data formats.

Yeah, certain ops can only be done from the main thread, since every class instance for decoding/vis/dsp/output is considered a thread, which means you must keep in mind thread safety. For other parts of the API it gets lenient. The reason is because DSPs and input components can also be used for multithreaded file conversions/encoding. Plus, other components can call input decoder helper services to help decode files to PCM data. Same goes for DSPs too.

Some decoders do keep playing while the FB2K seekbar keeps at the end, which is normal behaviour. See kode54's decoders as examples of this. :) I'd highly recommend you see his stuff too, since he is a HydrogenAudio admin + FB2K alpha tester.

In other matters, sorry about me going nuts a while back. As some people noted a while back on the byuuboard, I have some...mental health...issues I really need to work on, very badly. So my mood can be very erratic. Apologies again for this.

[qwertymodo]

There are a few ways I could handle manifests. I could register them as known filetypes, which would allow double-click opening of full packs as playlists, or I could just keep .pcm files as the only registered type, and just do the manifest parsing inside the get_info() call without ever actually telling foobar2000 itself that the manifests exist. Either way, it would only mess with file association if you explicitly choose to register the file type with fb2k, and at least in the case of the .pcm files, it is my understanding that throwing an exception_io_unsupported_format() causes fb2k to try other handlers that might also be registered for that same extension, so hopefully that's the case. So, at the very least I check the file on load for the magic "MSU1" bytes at the start of the file to verify that it is, in fact, an MSU-1 file, and not some raw audio format.

As you said, a lot of decoders handle looping the same way, so I'm not too worried about fixing that. One thing I may change is to have tracks with their loop point set to 0 not loop (though if they actually are looping files you can still test them by setting the playback to repeat track, I've tested it, and it buffers well enough to work gaplessly).

As for the other stuff, all I can really say there is I hope you can get some help with that that works for you. You're obviously bright and have contributed quite a bit to the emulation community, but it is a community and it tends to benefit the most from people who are able to work together. Best of luck to you there.

[ghost]

True, you could just allow bml's to be read and just not associate them. And plus you can throw exceptions if your plugin doesn't support that PCM file format. I don't see why not thats a problem, though a BML playlist service would be cool.

I'm somewhat interested in working on wav2pcm too. Would be cool to add ReplayGain to it, as well as MP3/FLAC/OGG decoding (those seem to be the most popular formats, though SoX decodes pretty much anything, so does ffmpeg 😮 )

[qwertymodo]

I have a batch script-based utility using sox and nongnu-normalize that has served me quite well https://github.com/qwertymodo/msupcm and I think DarkShock was also working on a utility to basically implement the same thing as a single native application using libsox https://github.com/mlarouche/msu1-audio-tool

[ghost]

libsox? Nice, didn't know there was such a thing.

[qwertymodo]

This thread has actually prompted me to start playing around with it myself. So far, I have a project built from scratch that's right about at the same point as DarkShock's, config parsing is working, and basic trim functionality is working in libsox. However, I've done a full build of libsox with all dependencies, so it actually supports all of the various filetypes (at least I think so... I haven't tested .mp3's yet, those are probably the trickiest to get built in). Now, if I can get fading, mixing, and concatenation working, that pretty much covers the entire feature set that I need (with things like cross-fade simply being a combination of those 4 effects), so I may just go ahead with that.

[qwertymodo]

@mudlord sooo... now this exists https://github.com/qwertymodo/msupcmplusplus