Previous Page | Next Page
- by unknownfile at 10:12 PM EDT on March 26, 2007
- you do it mouser :)
- by dag at 1:36 PM EDT on April 6, 2007
- Ok I did some basic voodoo magic (aka trial and error with a modified bero's decoder) and got them playing though slightly off. Some scaler isn't doing his job properly (or maybe the chunks thus the scales are misaligned ). I'll try to make them play correctly and even update the source code if needed but maybe this is enough for you guys? I'm not used to deal with ADPCM data so...
I'm pretty sure the header is the same btw.
edited 1:41 PM EDT April 6, 2007
- by hcs at 6:32 PM EDT on April 6, 2007
- The header does look the same, yeah. The trick with audio decoding is that you can be very far off an still produce something that sounds almost right, we're very good at picking out the original audio in the noise.
I haven't worked on this new format since the day it was first mentioned. Could you post your modified code so we can take a look at it?
- by dag at 7:28 PM EDT on April 6, 2007
- I don't have much to post (yet) really, I just made some quick changes to find a culprit. Basically I thought the noise was caused because the samples were overscaled, so I tried "underscaling" it and it sounds somewhat close (I hope I make sense). Well, no noise but not quite like the original song either, but you are probably right and I'm far off anyway.
However I don't think they changed the decoding method after so long (they've using the same format for like 8-10 years) so it's got to be some small detail here or there. I can't disassamble but I'll try to check how are the samples being processed and post if I get better results.
Btw, the "old sample" 1/2 scale is hardcoded to 0x7298/0x3350, any reason for this or just some magic number that works?
- by hcs at 6:36 AM EDT on April 7, 2007
- That magic number was probably hacked out of an ADX decoder by bero. It is a fixed point representation of ADPCM filter coefficients.
- by dag at 6:52 PM EDT on April 12, 2007
- Ok, after a closer inspection here is what I gather. Seems the sample format is the same, with same decoding (similar patterns), same length (18B), big-endian etc. However the scale (first 2 bytes of a 18B block) is very different. In the old version the scale is just a number, but the new one has some strange values.
It doesn't seem like a (processed) single number to me, maybe it's using other values or some lookup table. Here is some scales from some unrelated files (even the sample rate varies), format is left-right block scale starting from the beginning.
File1 / File2 / Sampl0408 / Sampl0400
4981-7A2A / 4C99-7F18 / 49E1-0000 / 0000-0000
103D-4266 / 1697-45D2 / 1068-42EC / 0000-0000
4B2B-2231 / 4E02-270B / 4B70-22A4 / 0001-0000
02B0-51A6 / 07D2-5494 / 02FD-51DE / 0004-0002
3F46-08E1 / 3C6D-0B2A / 3F0F-0890 / 000E-0004
07B4-7EAA / 06DF-7F08 / 078C-7ECE / 0009-0002
64C6-6C12 / 654B-6D18 / 649D-6C86 / 000C-0002
5E99-095E / 5F9B-08F7 / 5E11-09BE / 0008-0002
7C53-0EBC / 7C8E-0EDA / 7C24-0E77 / 0005-0003
46FC-323F / 4EA1-357D / 46AE-32AF / 0007-0003
...
See the pattern? Silence is still all 0's btw.
Here is a samples that could be useful, the same song with the old and new format. The old is from a video but they have the same number of samples and they should be close - http://www.sendspace.com/file/169dlr
I hope this helps, maybe you have seen similar patterns with other ADPCM formats? I can't think of much else. Next is learning R59000 assembly I guess.
edited 6:55 PM EDT April 12, 2007
- by commaasterisk at 10:26 PM EDT on April 19, 2007
- Sorry I haven't introduced myself to the forum or anything. I wanted to put in my two cents regarding the new ADX format... I also have to excuse myself because I'm not really a programmer.
I've been doing some testing on my end (using Okami's ADX sources) and can somewhat confirm what dag is saying.
The scale bytes are significantly different, however, I'm not sure if that is the cause of bad quality sound. For instance, if you lower the base volume to 0x0050 it will approximate the correct volume to where you can make out the music much better, yet it's still noticeably distorted. My (very limited) understanding of the decoding would seem to imply that this shouldn't be the case if it were merely a scaling issue.
After playing with the scales in various different configurations, including bit-shifting them in the opposite direction (yeah, they're that much different...) and removing them altogether and forcing amplification via Audacity, I'm convinced now that the scales aren't the main problem.
Then again take that with a grain of salt, I don't know the first thing about ADPCM decoding. If I'm way off the mark just ridicule me :)
- by dag at 1:55 AM EDT on April 20, 2007
- No, changing the base volume doesn't work because scales aren't direct numbers anymore (just check the list I put). Even if the volume is low they are amplifiyng the samples incorrectly with some random value.
If you make the decoder to use a fixed scale the samples aren't getting correctly amplified either (thus the tracks sounds a bit weird), but you can see the decoding still creates a close sound. I did try processing each scales in a few ways but I doubt you can get a correct scale from a single value.
- by commaasterisk at 2:55 AM EDT on April 20, 2007
- Er.. nevermind. You're right.
Here's how I proved it:
I modified Bero's code to ignore the scale altogether. Converted the "working" ADX (400) and the "new format" ADX (408). Popped them both open in Audacity and amplified them using effect->Amplify.
They both sounded pretty much identical! That settles it for me-- definitely a scale issue... Now how do we make those wacky bytes fit...
- by hcs at 6:57 AM EDT on April 20, 2007
- er, I'd think that what that would do is just create samples that are too small for the history mechanism to do anything useful with, and all you're seeing is the deltas.
Previous Page | Next Page
Go to Page 0 1 2
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source