- by hcs at 7:04 PM EDT on March 19, 2017
- I was mostly agreeing with you. Any butthurt is due to an uncomfortable chair.
- by AnonRunzes at 7:45 PM EDT on March 19, 2017
- "Part of the deal with MTA2 is that it is like MPEG in that it has more than just audio in the file (subtitles, lip sync, video), and there can be multiple audio streams, so you usually want to demux it to get just the audio for our purposes."
To be honest, I've never imagined MGS4 could use a format that did more than just audio(especially since "MTA2" is actually a newer version of the MTA format that originated on MGS3 as "MTAF" - the only changes from the former to the latter was an entirely "new" codec alongside more capabilities as the ones you've stated).
Perhaps that`s why your tool could only extract audio from MGS4 archvies alone, compared to sdt_demux.py by Nisto which could extract nearly every filetype imaginable based on .sdt-like headers(so long as a single file is accepted), but I doubt I`ll modify the script for MGS4 anyway considering I`ve been stuffing my HDD with a few EA and Ubisoft games for research purposes.
"I was mostly agreeing with you. Any butthurt is due to an uncomfortable chair."
Well, I stopped reading after the first paragraph for the first time for fear that I would provoke that reaction. Really.
Well, speaking of .wem files... they do have loop notes, though. There is a "smpl" chunk in a .wem header, so why can`t ima_rejigger5 support that too?
edited 8:14 PM EDT March 19, 2017
- by hcs at 8:23 PM EDT on March 20, 2017
- re smpl chunk support in ima_rejigger5, there's no reason it couldn't support it, the reason it doesn't is that it'd be extra work that hasn't been done yet. The whole ima_rejigger series was based on a false assumption about how WWise IMA works, so I really didn't put a whole lot of effort into it once it got working.
In other news, just had my ass saved by install steps 11-16 of here; I tried to install Ubuntu on a Mac where I was already dual-booting Windows 10, after that Windows wouldn't boot. Turns out I had to kill the hybrid MBR which apparently the Ubuntu installer had added, all 3 OSes work fine now. Whew!
- by SmartOne at 9:13 PM EDT on March 20, 2017
- Let me guess: the performance of your video hardware in Linux is awful.
I thought it was fun being the only person who didn't jump on each of Apple's latest incremental OS X upgrades (which provided no significant new features) in an Apple workplace, and then pointing out the crashes of oh-so-friendly Apple software as the no-longer bleeding edge OS version became stale.
Safari with its uber-smooth scrolling, I'll admit, is the best way to browse the Internet, though. Too bad Microsoft doesn't take a hint.
- by bnnm at 2:39 PM EDT on March 21, 2017
- @hcs - a question/comment about WWise MS IMA.
You mentioned before vgmstream's MS IMA decoding may miss some samples, so out of curiosity I tracked down Microsoft's C implementation.
What they do is write the block header sample, but discard the block's last decoded sample (while vgmstream ignores the header sample and keeps the last sample).
The last block sample and the next header's sample may be the same, or vary slightly. This means vgmstream misses the very first header sample (so in essence the file is +1 off) and some samples are (unnoticeably) off.
Could be fixed but not exactly a super important.
Is Wwise using this feature somehow? From the ima_rejigger readme it kind of sounds like this but I'd appreciate some pointers before I delve into the code.
- by hcs at 5:51 PM EDT on March 21, 2017
- Could you point to the MS implementation? I had thought that it kept both the header sample and the final decoded sample, thus the samples per block is odd (iirc samples per block is given in the extra fmt bytes). See case AV_CODEC_ID_ADPCM_IMA_WAV in libavcodec.
Wwise doesn't use the final decoded sample, the final nibble is always 0. Maybe that's the same as what MS's official implementation does, but I doubt it. When I tried to "rejigger" wwise (it's also interleaved differently) and set codec 0x11, every decoder I tried (sox and ffmpeg) had artifacts.
edited 6:01 PM EDT March 21, 2017
Though it would make sense if this was different in some Xbox-specific stuff, the above is about RIFF WAVE. Maybe it would make sense for vgmstream to use the header sample and skip the last sample. Especially if it turns out to be always 0 as in wwise, though I'd expect some noticeable artifacts from that that I'd hope we'd have noticed.
edited 6:10 PM EDT March 21, 2017
- by bnnm at 6:15 PM EDT on March 21, 2017
- Here it is.
It's og Xbox's (cough XDK cough), but the docs say it's a wrapper around Windows MS IMA with a fixed block size.
I see the decoder parses "cSamplesPerBlock - 1" but in all honestly I didn't build it myself to test it.
However ToWav, which I think just uses MS's libs, also agrees with this and writes the very first sample.
It's not unthinkable every decoder out there is incorrect, I guess, since the difference is very small.
Incidentally I don't think any PS ADPCM decoder is HW accurate either (I've seen several slightly different implementations), but I don't know enough to evaluate and fix it myself :/
- by hcs at 6:35 PM EDT on March 21, 2017
- Samples per block should be independent of block size, but I know at least sox and ffmpeg ignore it (ffmpeg actually requires it to be sample nibbles +1). This is wrong, as the Xbox fixed size of 64 would otherwise be impossible to specify. It does actually look like this SDK encoder does put a 0 for the last nibble, so we may have always had problems with Xbox IMA if they used a similar encoder.
It would be informative to try out some sample data with and without the fix you've proposed, or add a check for the last nibble == 0 to see if this holds up.
edited 6:39 PM EDT March 21, 2017
HCS Forum Index
Go to Page 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182
Search this thread
Show all threads
Reply to this thread:
Halley's Comet Software
Generated in 0.0574s;