Hard Corps Uprising rip problem by vagrant18 at 12:30 PM EDT on April 17, 2014
Is there a way to make the rips work properly with vgmstream? Both PS3 and X360 versions don't work as they should, most tracks are broken and playback with lots of noise. I wonder if the rips are bad, or is it related to vgmstream?
Obviously X360 tracks or FSB containers coming versionof the game for that platform simply won`t play in vgmstream and they even shouldn`t since FSBs in that pack contain XMA-encoded audio but when it comes to discussion of difficulties regarding playback of PS3 ver. files I`m quite uncertain what to blame in that specific case. To be honest I`d swear that those disastrous noise and static inclusions in the most random sections of most tracks coming from the set in question were actually originated not from a somewhat faulty rip but from too late and therefore mostly non-efficient file recovery attempt. I`ve had similar problems myself trying to recover some deleted files but launching a special procedure way too late. And what`s specifically worth noting is that playback probs occur not matter what to play: original FSBs or extracted LWAVs \ XWAVs as each track begins and ends ear abuse at all the same points.
Oh and I almost forgot to point out the way you can convert X360 ver. FSBs. You can run either FSBs or XMAs (although you`re required to rebuild them to XMA1 first if memory serves) through ToWAV by Xplorer.
For PS3 it could be one of 2 issues. If its MPEG FSB, the frame padding isn't supported by the decoder we have in vgmstream, or it's another IMA variant that isn't supported yet.
It`s definitely ADPCM since FSBExt extracts WAVs out of FSBs and they can be played with help of vgmstream after addition of either "L" or "X" letter to their extensions. However what I forgot to mention the last time and what serves as just another proof of my faulty file recovery theory is that whenever those aforementioned ear abusive sections begin a listener simply cannot miss the fact that music noticeably changes and what sounds at that time does not and should not belong in there. The best explanation I have for this once again involves some details of file recovery procedure gone wrong. I mean those pitiful cases when recovery`s attempted way too late and most if not all wanted files have already been partially overwritten with portions of different ones. With this in mind I can offer at least one pretty reasonable explanation for a problem we have with PS3 tracks. Although I haven`t done it myself I can suggest that someone compares playback of a few test pairs (made of PS3 and X360 counterparts of select tracks) and decides whether I`m right or wrong.
Thanks for the heads up, I managed to convert the X360 tracks into something playable. Even the audio quality is very good.
What I don't understand is why the archives don't share the same file size. The audio files are of identical format, but when extracted the PS3 files are larger, and when compressed (~34mb) they are smaller than archived X360 files (~130mb).
I tried to find a difference in audio quality by checking a rip somebody made from PS3 version, and both X360 and PS3 share the same audio quality.
So, basically, I really don't understand the situation for PS3 music files, and I'm still unclear if it is a bad rip, or just an encryption-related issue.
The audio files are not of identical format, granted most file here and there have FSB extension but that doesn`t mean they contain files encoded the same way. FSB is just one of widely used container types and given its nature and original purpose it can contain tracks encoded using multiple codecs: not only some variant of IMA (?) ADPCM and XMA for PS3 and X360 versions of our game but many many additional ones like MP2 / MP3, almost all existing platform-specific ADPCM variations, even PCM and probably quite a few others.
Since it`s ADPCM they decided to use on PS3 music should take way more space on a disc when compared to X360 solution and PS3 rip is actually significantly bigger in unpacked form then its counterpart. However the former set is for some reason much much smaller in an archive that leads me to an assumption that there`s too much duplicate data in it. One can use it just as another argument in proving my incorrect recovery theory and I think it`s quite a strong one: just think about almost 10% compression ratio (uncompressed rip takes almost 10 times more the space than a zipped set)!