Video CD card FMV
- Thread starter EliteEvi;
- Start date
antime
Extra Hard Mid Boss
ADPCM algorithms work by quantizing the difference between the actual signal and a predicted value. If you decompress the result you will get a signal where the quantization has aldready been performed, and thus you will get the same result if you compress it again.
For example, if you look at an 8-bit sample you will get values that are in the range of 0-255. But if you look at the difference between one sample and the next, most values will be quite small. So you get a great idea: instead of storing each 8-bit sample you store only the first sample as an 8-bit value and after that only the differences as 4-bit signed values. If at any point the difference is greater than what can be stored, you store the maximum and continue from there.
If you now decompress your result, there will be no two consecutive values where the difference is outside the range -7<=n<=8. This means you can repeat the decompress-compress cycle as many times as you like, and the result will stay the same. However, if you compare the output to your original you will most likely see differences.
(The above is a differential PCM coding algorithm. ADPCM algorithms will predict the next encountered value using some scheme, and store the difference between the predicted value and the actual one. There are some ADPCM algorithms that are lossless, but AFAIK most are lossy.)
No, but if the source material was anything other than 16-bit 44.1kHz the conversion process would be.
For example, if you look at an 8-bit sample you will get values that are in the range of 0-255. But if you look at the difference between one sample and the next, most values will be quite small. So you get a great idea: instead of storing each 8-bit sample you store only the first sample as an 8-bit value and after that only the differences as 4-bit signed values. If at any point the difference is greater than what can be stored, you store the maximum and continue from there.
If you now decompress your result, there will be no two consecutive values where the difference is outside the range -7<=n<=8. This means you can repeat the decompress-compress cycle as many times as you like, and the result will stay the same. However, if you compare the output to your original you will most likely see differences.
(The above is a differential PCM coding algorithm. ADPCM algorithms will predict the next encountered value using some scheme, and store the difference between the predicted value and the actual one. There are some ADPCM algorithms that are lossless, but AFAIK most are lossy.)
No, but if the source material was anything other than 16-bit 44.1kHz the conversion process would be.
Though it's important to note that the prediction has to produce the same values on output using only information from the first part of the file in order for the tecnique to work properly. This makes learning algorithms somewhat impractical.
I would imagine that most ADPCM implementations use some kind of regression on the previous samples modelling the waveform after a sine, quadratic or cubic curve. Some might do a simple linear regression for speed reasons.
A simple way to do lossless ADPCM would be to Huffman encode the differences rather than using a fixed value. That keeps the number of bits used down for the more common deltas, but allows the field to expand to accomodate the more common deltas for full lossless operation.
I would imagine that most ADPCM implementations use some kind of regression on the previous samples modelling the waveform after a sine, quadratic or cubic curve. Some might do a simple linear regression for speed reasons.
A simple way to do lossless ADPCM would be to Huffman encode the differences rather than using a fixed value. That keeps the number of bits used down for the more common deltas, but allows the field to expand to accomodate the more common deltas for full lossless operation.
I just had a look at the Dreamcast tools adx2wav/wav2adx. ADX is said to be ADPCM, too.
We could make a ADX player for Saturn. I wonder if the SCU DSP is suited to do ADPCM decoding, since the load on the SH2 CPU is heavy when playing ADPCM with SBL's PCM lib. A second reason is, that all tools I tried to create ADPCM encoded AIFC sound files failed to create Saturn compatible output.
We could make a ADX player for Saturn. I wonder if the SCU DSP is suited to do ADPCM decoding, since the load on the SH2 CPU is heavy when playing ADPCM with SBL's PCM lib. A second reason is, that all tools I tried to create ADPCM encoded AIFC sound files failed to create Saturn compatible output.
