Simple Amiga audio question.

[Thorham]

Here is an example of my implementation of ADPCM4.

All files are converted back to .wav so you can easily play them.

Thank you very much Much better than I expected, to be honest, especially 4 bit (and also better than IMA, it seems that IMA is for speech). Sounds good

If you decide to use this codec, I can pass you the source along.

Although I'm still playing around with lossless encoding ideas, I have a feeling I'm going to get stuck and need lossy anyway, so sharing your source code will certainly be appreciated a lot.

Probably 6bit is quite hi-fi too, but it's a little hazzle to implement since 6 is not a fraction of 8, so you need to decode always 4 samples at once. But if 4 samples turns out to be too poor, 6bit would be doable too.

Decoding 4 samples at once shouldn't be much of a problem to implement here.

[Thorham]

Haven't been busy with this for a while now... I think I'll just write an ADPCM encoder and decoder myself. I'll try lossless encoding once more, and I'm also tempted to soft loop the tracks, although it's quite a chore (sigh).

Anyway, thanks to all who've posted their suggestions and comments

One more thought: If one could do software channel separation and sound recognition/reconstruction, I'm sure the entropy of music would be better than 0.5, but just try to write it :roflmao:

[Thorham]

What I mean is this: If you have a tracked piece of music (all music is tracked), then each of the channels will play part of the music, one instrument at a time. The brain can easily separate the channels and recognize the instruments as independent samples, meaning it can convert a piece of music to a tracked format.

With a tracked format you can easily beat 1:2 lossless compression. A MOD recorded to WAV and compressed with, say, FLAC would be much bigger than the original MOD.

This is why I don't believe that the 1:2 ratio is dictated by nature, as bubblebobble claims. People simply don't know how to do it yet, because WAV to tracked format conversion isn't exactly easy to write, especially not without neural algorithms.

[Thorham]

The best predictors achieve roughly 1:2. Just accept this. Anything else is lossy.

I can only accept this if there's hard mathematical proof for this. If this 1:2 ratio is the result of the current best implementations, than it's circumstantial evidence, and not hard proof. If there is hard proof, then it's a fact, until than it's theory.

Anyway, the idea I presented is probably too hard to implement in this day and age anyway, and I just wanted to hear peoples thoughts about it

[Thorham]

Don't know if it's useful, but here goes

I've been away from the Amiga more than I would have liked. In the past, Karlos or somebody explained to me the process of cutting the first two bits off a WAV file in order to make it friendly with the Amiga. Since then I forget what I was told, would someone mind refreshing my memory?

Thank you!

What you have to do is endian convert each sample in the WAV file, because the bytes are swapped:

Code: [Select]


 move.w (a0)+,d0 ;a0 points to sample.
 rol.w #8,d0 ;swap sample bytes.


In case the samples are stored as unsigned integers you can convert them to signed like this:

Code: [Select]


 sub.w #32768,d0 ;d0 contains the sample.


After that you can convert the sample from 16 to 14 bit like this:

Code: [Select]


 asr.w #2,d0 ;d0 contains the sample.

I sure hope I didn't make any stupid mistakes

[Thorham]

Are these command lines for a program or something? I'm sure if I start typing that stuff in CLI that nothing will happen but errors, so what's this for?

Oops! It's assembly language (language of the computer in readable text format). Seeing how this is the programming section of the forum, I thought it might be useful to you. Sorry

Why do you need to convert 16-bit WAV's to 14-bit anyway? Tools like Play16 etc use AHI which does the conversion from 16-bit data to calibrated 14-bit as it plays.

Playing WAVs is better done with programs that have their own 14 bit calibrated player routine, because AHI sucks for Paula, and isn't needed for this anyway. Play16 uses it's own replay routine, and Hippo player, which can also stream big WAVs, also has it's own replay routine (but I'm sure you already knew that ).

Just the one. The conversion from unsigned to signed should have subtracted 32768, not 128. You'd subtract 128 for 8-bit unsigned sample data.

Yeah, you're completely right, of course. Guess I was typing too fast

[Thorham]

Actually yeah, Play16 talks directly to the calibrated "cybersound" driver. However, if you have AHI, far from sucking, it performs quite well. Later versions, however, are far too cpu hungry it seems.

The point is that AHI isn't needed at all for 14 bit+calibration. AHI might be cool for audio cards, but for Paula it isn't needed in my opinion (yes, that might have some small back draws, but I still don't use it)

This thread is confusing.

That's because it's the wrong thread to post your question in. This thread is about what a 14 bit driver does to 16 bit samples, and about audio compression. Also, it's programming related, and doesn't have anything to do with audio software such as Octamed. Note that this thread is in the development (programming) section of the board. It's better if you make your own thread in an appropriate part of the forum