Previous Page | Next Page

by Alpha23 at 11:19 AM EDT on June 1, 2018
I'll gladly take the raw IMA stream! :)
by Nisto at 7:31 PM EDT on June 1, 2018
Actually, I just realized there's another deal breaker. (It's been a little while, so my memory is not too fresh. Sorry.)

Anyway, there isn't really such a thing as a "raw" IMA ADPCM stream. There are special frames that contains sample history (16-bit PCM) and a step index, which are of course crucial for decoding the ADPCM-encoded samples. So the only thing that really makes sense is extracting the complete audio frames, so that you can detect and extract those parameters.

The decoding routine in h4m_audio_decode works on frame buffers, so you are free to copy that if you want.

Sorry if I seem avoiding, but if you are okay with this, I'll see what I can do.
by bnnm at 8:13 PM EDT on June 1, 2018
I think I'll add this to vgmstream later, doesn't seem too complex.

Then, demuxing by throwing out all vid frames and adjusting sizes and counts should be enough.
by Alpha23 at 6:17 AM EDT on June 2, 2018
That sounds FANTASTIC!!!!! :D
by Nisto at 6:56 AM EDT on June 2, 2018
Okay, fair enough. So I'll keep the 'HVQM' header and just toss the video frames. That way we maintain a proper extension, too.
by hcs at 9:24 AM EDT on June 2, 2018
Great work Nisto! If it's ok I'll grab 0.5 and update the old code in my GitHub repo. Sorry I missed the progress in here till now.
by bnnm at 2:02 PM EDT on June 2, 2018
@Nisto/hcs - do you happen to know if output is sample-accurate?

I see every frame it writes the header hist sample (line 300), then decodes all nibbles but the last (to write an even number of samples). This kind of model is used in some IMAs (XBOX IMA), but *not* others (Apple IMA4).
The output difference would be minimal though, just curious.

EDIT: checking some samples it does seem most frames are packed considering this extra header sample (ex. 0x643, with 0x642 data size/samples + header) so it must be used.

edited 4:57 PM EDT June 2, 2018
by hcs at 6:40 PM EDT on June 2, 2018
Oops! I wonder if that's the reason for the Resident Evil streams going out of range?

Oh, you were agreeing with the old impl., misread.

edited 8:34 PM EDT June 2, 2018
by Nisto at 11:48 PM EDT on June 2, 2018
@bnnm: I'm not entirely sure I understand what you mean to be honest. Are you saying it is (or could be) writing one sample too little, or one sample too many? If anything, I can see if it might write one sample too many, because of this line:

for (int i = 0; i < 2; i++) {

since a mono stream might contain two samples in a byte, and this doesn't allow the program to check if there are actually any remaining samples after the first nibble (since it's kind of "trapped" in processing both nibbles). Is this what you're getting at?

The sample count in the frame header definitely includes the history sample. Unless the RE0 code is wrong, too.

Regardless, I'll definitely try to fix the issue, whatever it is. I just hope you can enlighten me a bit more on this.

Also, I've implemented demuxing capability now, but the code is very sloppy (sketchy even), so I'll see if I can do a somewhat decent rewrite before I release it.

@hcs: Thanks, mate. You are welcome to update your repository on GitHub.

edited 11:51 PM EDT June 2, 2018
by Alpha23 at 3:48 PM EDT on June 3, 2018
Thanks for all your work!
I'm eagerly waiting for a demuxer. :)
You see, I'm collecting VGM in raw form and I need the demuxer to NOT save the h4m videos but only the audio stream. Only a rip with demuxed videos is truly complete (at least in my eyes).

Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=]Link[/url]


HCS Forum Index
Halley's Comet Software
forum source