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?
Guess I'll have to check all MCA sets after you share the updated build and rerip them. Shouldn't be a problem though, it's best to keep original files either way. :)
In you want to check before I add it to kode54's repo: https://www.sendspace.com/file/dtni8w
I tested a bunch of non-fixed sets and seems correct now. Older/newer MCA versions may require tweaks (v4=EX Troopers, AA5; v5=AA6, Dai Gyakuten, MH G/S/U4, Megami Meguri).
Works great with almost everything I tried. Resident Evil - The Mercenaries 3D [Biohazard - The Mercenaries 3D] (2011-06-02)(Capcom, Tose)(Capcom) seems to play static now, not sure if it was a 'fixed' rip or not.
Included are the .mss(the original one) and .genh(the converted one) files included in two of the samples I provided. Compare the former to the latter, and you'll see that the .mss file ends with a few samples being cut on vgmstream while the .genh file ends by getting though all the samples to play on vgmstream, exactly as the .mss file should be playing.
@bnnm: would it be possible to add stereo support to BCWAV? I'm seeing a lot of LEGO 3DS games use BCWAVs, with separate files for L and R channel. Adding _L and _R to the filenames doesn't make VGMStream play them in stereo though.
I don't use winamp myself but if there is some interest I can post updated versions every now and then. (or maybe beta versions for wip features before they go to foobar)
I've been following the vgmstream updates & have been applying most of them (just not the ffmpeg aspects so far) to a local copy I'm using (though it's limited to working within my WACUP project).
but I can look into making a version that either works just with 5.666 or if there is the demand version independently.
Seems that its endianess got reversed for the header.
by ChillyBilly at 12:28 AM EST on December 22, 2016
Guess this is a good a thread as any to ask about this, so... is it possible to add improved support for MSF files to vgmstream? Because most of the ones I try to play simply don't play at all (this counts for both games I've ripped myself, and files that were already uploaded to the ps3.joshw site, like Galgun and Mamoru-kun wa Norowarete Shimatta). And unfortunately, no other solution to "fix" MSFs have worked for me so far, which leads me to my little request here. Thanks in advance if you can look into it.
@Knurek - sure: https://www.sendspace.com/file/n6sw4d It also has (beta?) HEVAG support. I'll try to automatize the upload process somewhat (still need to link to kode54's "official" FFmpeg DLLs and stuff).
@Dro - if you want I could incorporate your changes. I test the DLL with an old Winamp 5.61 but I didn't have any particular problems, FFmpeg included.
@ChillyBilly - they work in test/winamp but not in foobar, somehow... I'll check. EDIT: seems FFmpeg DLLs weren't compiled with MSF support.
Done. And please see ext_libs/ffmeg_options.txt to see what I actually use to build it, using the specified base build kit. I basically answer shared, GPLv3, yes to try Windows XP support, no to pretty much everything else, and then that specified options file in the build directory. For 32 bit only, it will use about 2.55GB of NTFS disk space, and produce output in build\local32\bin-video\ffmpegSHARED\bin.
by ChillyBilly at 2:30 AM EST on December 24, 2016
Just wanted to mention that I installed the latest update for foobar, and now those MSF files play like a charm! A million thanks, bnnm and kode64! :D
@bnnm: Could you take a look at the recent 3DS rips for FIFA games? They seem to use standard EA container (SCHl header with chunks), which VGMStream supports (provided you rename the files to *.eam). But I'm guessing VGMStream expects PS2 ADPCM, whereas these files use Gamecube ADPCM. (I've seen them used on PSP and VITA as well, with AT3 and AT9 streams respectively)
I decided to upload my builds here so I don't have to manually post them all the time: https://github.com/bnnm/vgmstream-builds
Not ideal, until I find a better way to host them...
@Knurek - the headers go to EA ADPCM. I tried to force a bunch of codecs without success. Since I don't know much about GC ADPCM I'd need some pointers, as well as examples of other EA containers.