vgmstream latest beta by bnnm at 12:15 PM EST on December 6, 2016
Since I'm doing some changes lately I thought I'd upload an unofficial beta of sorts: https://www.sendspace.com/file/6yxx2w (ie.- works for others? WinXP? AT3 loop hiccups in older systems?)
Basically now enables FFmpeg in Windows for AT3/AC3/AAC/OMA/MSF/whatever support (may need some renaming, see changelog.txt), also can load ADX/HCA keys externally. at3plusdecoder.dll isn't used and there 3 new FFmpeg DLLs (only enable common VGM formats but can be swapped with full DLLs).
foobar2000 will probably be updated after some FFmpeg issues are sorted out.
I'm thinking of adding some more stuff like XWB/XMA later and some random ideas. Winamp can't play 5ch btw (any Winamp expert?).
Seems to work fine for me - Win10 x64 Had AC3 ACM stealing files from VGMStream, but after removing that they get played fine.
AT3/AT3+/AT9 (whenever the last one gets supported) still have wrong loop valuess - you don't take into account the zero sample value from the fact chunk if Stream info window is to be believed.
Thanks, can't wait to test it. I would love to see XMA support so the variety of containers could be "meta-ized."
Not sure if it's possible, but it might be convenient for people to be able to drop movies on and playback only the audio tracks (Bink, XMV, etc.). Of course, there's a ton of challenges in that with multi-language movies, etc.
I'm very interested in your idea regarding a helper file for new "meta" formats and have been thinking about how it might work over the past few days. Depending on how it's implemented, the same helper files could theoretically also be used to generate a database, wiki, website, etc. to document VGM formats.
AT3/AT3+/AT9 (whenever the last one gets supported) still have wrong loop valuess - you don't take into account the zero sample value from the fact chunk if Stream info window is to be believed.
The value is at 0xC from start of fact chunk. Subtract this number of samples from the loop start and end values. Knurek's discovery was recently incorporated in atracloop. See code here (it lacks good error handling, but works).
Bink, XMV and stuff are supported by FFmpeg, so 0 effort to add them (recompile DLLs and swap). If you want more FFmpeg formats here they are: http://pastebin.com/nUd2aaEv You can rename files to .vgms/.vgmstream to force them info vgmstream btw.
The AT3 loop values should be fine --I did quite a bit of testing. You are supposed to ignore samples before the "zero sample" in the fact chunk (which can be at 2 positions depending on chunk size), while the loop points are absolute. Since vgmstream doesn't ignore them you can't substract yet or it'll "desync" (rarely noticeable but I've seen a few).
I plan to fix this "skip samples", since sometimes the encoder introduces garbage there.
Helper files yeah. I think it'd be good for vgmstream to evolve into that direction. Like meta description for simpler formats (ie. some format akin to vgmtoolbox's GENH generator), FFmpeg for generic formats, direct vgmstream support for more complex formats or features.
I don't think loop points are absolute. I made some encoding with at3tool, and even if I provided wholeloop for parameter (so, 0 for loopstart, #sample_total for loopend) the values in RIFF header were shifted by the 'zero sample' value. Not sure how FFmpeg handles that, I don't recall the loopshift being much of a problem provided you didn't use Hi-MD Renderer for decoding.
Example to clarify, encoding with loop_start=0 to loop_end=12000. at3tool encodes: zero sample=1000 (silence/garbage up to that sample), loop start=1000, loop end=13000
When at3tool decodes to wav it skips 1000 samples first so your .pos loops should be start=0 end=12000 (substract).
When FFmpeg/vgmstream decodes it doesn't skip 1000 (for now!), so your .pos should be start=1000, end=13000 (don't substract).
We are more or less saying the same thing ;)
It's often not noticeable but I have some samples affected by this subtlety.
"You can rename files to .vgms/.vgmstream to force them info vgmstream btw." I did try to do that, but it doesn't work when playing them on vgmstream(through test.exe). Maybe I'm doing something wrong?
I'm 100% in favor of helper files, it solves so many problems, e.g. format detection, renaming, difficulty of compiling. I didn't see where you mentioned this idea, is there another thread (or some discussion happening on IRC?). As a follow-on to snakemeat's idea, wouldn't it be cool if the wiki for documenting formats could contain literate code for the meta helper file?
I've always gotten hung up on the details of the file format, should it be some reasonably powerful embedded scripting language like Lua, should the API just be the VGMSTREAM struct, should all the metas be rewritten this way to reduce the amount of C, what about that mess that is the rest of the driver code, etc.... I'll try to stay out of this to avoid confusing the issue.
Thanks to bnnm and kode54 and others for continuing to breathe life into the old project!
@AnonRunzes - renaming only works for some FFmpeg extensions. IE. .oma isn't registered/won't play in winamp/foobar but .oma.vgmstream should. test.exe doesn't need any renaming and will eat anything btw. I'm haven't decided if .vgmstream working globally would be good or not.
@hcs - I passingly mentioned it, after suffering the many hoops to add a PS2 format.
Though first I want to make FFmpeg/new formats more stable, add some ideas and maybe simplify (update docs, clean code?). I mostly wanted to add looping normal-ATRAC3/AC3 (Tokyo Jungle <3) but might as well fix some things until I get bored.
We could do a thread later but ideas for the format: - very simple, get it out ASAP (less work for me) - probably binary for simplicity; rely on generation tools (vgmtoolbox, wiki-language-to-file) - versioned, iteratable (v1-binary-parser, v2-text-parser...) - commands of known stuff: "$num_samples is in @0x10" (kinda like vgmtoolbox's GENH maker) - if game needs complex XOR/layouts/codecs: point to C/FFmpeg - easy to stick into some folder, or pre-compilable into the exe - coexist with the current metas, offload/disable on compile little by little. - no big changes to the codebase (self-contained) - take hints from FFmpeg, act as a demuxer for FFmpeg codecs in some cases (facilitate migrating) - maybe convince FFmpeg devs to export loop points for full support of complex formats
bnnm: Could you take a look at Capcom MCA files as well? Some of them play fine, some play as static. The static ones play fine if you add 16 bytes of 0x00 to the beginning of the stream, so I guess something about the starting state of the decoder for the format is wrong?