RIFX Ogg vorbis file by OrangeC at 1:16 PM EST on November 30, 2009
I have a file here that seems to be a vorbis format but has a rifx header, is this mixed wav/ogg hybrid or something because i cannot get it to decode.
RIFX is just big endian RIFF, but that doesn't help him, as RIFF Vorbis is itself tricky to deal with. FastElbja brought these to my attention a while ago, and while I know in general how to deal with them I haven't been able to go through all the fun to actually implement it.
by pietastesgood at 9:13 PM EST on November 30, 2009
So basically, this Riff Vorbis is an ogg file with a fake Rifx header?
Would there be any other way besides adding on the original full ogg header to make this decode?
The problem is that Ogg doesn't enter into it at all, it's a raw Vorbis stream. Without the Ogg wrapped around it the normal library can't do anything with it. It isn't just a matter of a header, the whole stream would need to be repackaged. There's likely a way to set up the Vorbis decoder to work directly with this file, though I don't know how to go about it. Some day...
Seems similar to what's discussed for EVE Online, with RIFX instead of RIFF.
That makes it Audiokinetic Wwise, as their site confirms, which has a custom Vorbis implementation. It looks like they've made their format even less standard now, though, as there aren't any identifying strings from a normal Vorbis stream. I can identify a few aspects of the structure, but I don't really know enough to be able to tackle this. Yet.
edited 7:16 AM EST December 1, 2009
Hmm, release notes for 2009.3 say:
Codebooks have been removed from the Vorbis file headers and moved to a decoder library resulting in less runtime memory usage, less space taken on DVD, and smaller prefetch loaded in RAM.
Which would explain why I couldn't find anything looking like a standard codebook.
You can get the SDK from their site (the form doesn't need a valid email). I haven't tried it on these files yet. The EVE guys didn't have any luck and they were trying it with PC games, it's fairly likely that the 360 version is different enough that it's totally unsupported.
I'm having a look at it anyway. I looked at the RIFF .ogg files this produces, they seem similar enough to the RIFX that it might be the same version. In particular it looks like the same situation with the codebooks being left out and instead part of the library. It looks like their decoder is a wrapper around Tremor so hopefully I won't have to go too deep.
Ok, this does essentially the right thing. ww2ogg 0.0 converts Audiokinetic Wwise RIFF/RIFX Vorbis to normal Ogg Vorbis. packed_codebook.bin is extracted from the SDK and is needed for the converter to work, as the codebooks aren't stored in the file anywhere. The format is pretty much the same as the standard besides that, but with reserved and unused fields left out of the setup bitstream. Worked on the one AC2 file you gave, I think. Those of you who know what it sounds like will have a better idea.
Here's a fix for the other AC2 ones with some more chunks, apparently for looping: ww2ogg 0.1
I'll take a look at the old file later.
One more fix, handle subtype with no seek table: ww2ogg 0.2
edited 10:32 AM EST December 4, 2009
A little more handling for cuepoint lists (just ignored). ww2ogg 0.3
At this point it should work with everything from Assassin's Creed 2, except for 470157058.wav which is XMA2. xma_parse can pull out the stream like so: xma_test 470157058.wav -o 800 -b 10000 -r 470157058.bin
It's cut off, but I assume that's because it should loop.
Just wanted to give an update to this old thread, I added support for the Divinity 2 style files in ww2ogg 0.7. Unfortunately the files banks, so you have to use some method to cut out the RIFF chunks so that ww2ogg can deal with them. Just splitting everything from one RIFF to the next RIFF will do.
It seems that ffmpeg chokes on some of the files ww2ogg produces, at least from the Batman: Arkham City rip. This, in turn, breaks recent versions of foobar2000.
I shared the files with a fellow foobar developer, and he says the ww2ogg version is five releases behind.
"converted from Audiokinetic Wwise by ww2ogg 0.16"
Specifically, "012 - BAC012.ogg" from the Batman: Arkham City rip. The code books seem to be fine, as it decodes with plain libvorbis. The trumpets sound a little scrapy, or weird, but it plays for the full duration.
In foobar2000 and ffmpeg, whole packets seem to be dropped seemingly at random, causing the duration to be almost a full minute less than the last granulepos reports.
Hm, at 0.16 there's some chance it has to do with the prev/next window type bits not being set properly for the modified packet format; ww2ogg doesn't rebuild those correctly until 0.19.
libvorbis doesn't use those hints but others do, and revorb doesn't attempt to fix them. If you could throw an example file up I could confirm/deny this.
If this is the trouble it should be possible to fix even without reference to the original files.
EDIT: This file is supposedly from a game rip of Arkham City, and supposedly, the DLC rip does not have this problem, so perhaps the ripper updated their tools? The original game rip needs to be fixed still.
Those previous and next numbers should indicate the previous and next block size. Instead it is always reporting that the neighbors are short blocks, which means the decoder may use the wrong window or lapping (see the spec for details).
All the information is there to fix this, it only wants someone to do it. This may not be the only problem, but it is definitely one of them.
Well, if anyone wants to fix revorb, the source is available:
http://yirkha.fud.cz/progs/foobar2000/revorb.cpp
And with little modification, it could be compiled outside of Windows.
The way I see it, it would need to buffer a full packet ahead on the input file, and keep track of the size of the previous packet, where applicable. Then it could easily regenerate that information for the output packets.
Hmm...
EDIT: It would be most helpful if you could tell me which structure those previous and next members are a part of. Is it the ogg packet, or is it something specific to Vorbis?
Here's the relevant code from ww2ogg 0.21. Note that this depends on knowing the modes set up for this particular file, the long/short specification is per mode, (vorbis_blockflag) and packets only say what mode they use. As these bits are at the very beginning of a vorbis packet I don't have to deal with parsing the whole packet, I just read the mode bits and insert the window bits if it is a long packet.
Probably should have been more explicit, this code inserts the packet type bit (always 0) and optionally the prev/next window bits into the wwise packet, which misses them entirely. You will want, instead, to replace the window bits (which were always filled in 0 in an older version of ww2ogg).