Integrated PCM + ADPCM-IMA cinepak player

[+cubanismo]

Now that the basic cinepak stuff seems to be working well for me, I decided I wanted to encode a disk of music videos (One can only watch November Rain on Vid Grid so many times).  8-bit mono sound sucks for music, so I started looking at @Orion_ and @Zerosquare's IMA audio enhancements.  I wanted to use the regular stand-alone cpkdemo cinepak player though, so I looked at what it would take to use the new dspcode with that app.  That was too easy: You just copy Orion_'s dspcode.s file over and it works as-is.  I figured it'd be cooler if you could mix IMA and raw PCM files on the same disk or use the same player code with the skunk to play both types of disks, so I looked into what it'd take to merge the two together.  That was harder, and more to my liking.  Attached is a dspcode.s you can drop into the existing cpkdemo player source and it will auto-select the right codec if you make one small modification to your IMA movies:  Set the Audio Descriptor "Audio Compression Type" field to "2".  Right now I'm doing this with a hex editor after running my files through JagCinePak, but I'll update my cinefix tool to take care of it shortly for those that don't want to get intimately familiar with the various Cinepak file formats.

 

Now some questions for the audience:

 

-Anyone know what variant of ADPCM IMA encoding avi_ima_encode.exe uses/this decoding code expects?  ffmpeg lists 14, 2 of which (adpcm_ima_qt, adpcm_ima_wav) it can encode.  I started trying to compare the ffmpeg decoders with the DSP code, but figured I could just ask first.  I'm still working on my command-line cinepak conversion tool, and I'd like to pull as many parts of the process into this one tool as possible to simplify things.

 

-I've had this playing in a loop alternating between a PCM and IMA music video for a while, and it's relatively robust, but sometimes it crashes at the start of a video.  I'd like to chalk it up to Jaguar CD players being Jaguar CD players, but it seems less reliable at transitioning than the pure-PCM code.  It used to almost always crash when switching modes, but I tweaked the init code (The stuff just after DSP_ENTR) a bit to not assume interrupts are disabled to get it to this point, so I feel like I'm still missing a detail there to get it to 100%.  I did try disabling interrupts entirely for this portion of the code and it's been going strong like that so far, but the old PCM-only code doesn't need to, so it seems like it should be able to work with them enabled.  Could it be the old code is racy somehow and the fact that I added a ton of instructions here just exacerbates an existing issue?  I don't like using a fix I don't understand.

 

-Totally unrelated, but while testing the auto-detection, I had to hack the audio descriptor in the 68k code to set the right bits for ADPCM files (I just hard coded a list of ADPCM tracks matching the content on my test CD).  At first, when I had the bit in a different location, I was trying to do this with the following code:

; AUDIO_DESC is a long word in the DSP's memory
; Set bit 8 in that long word using a byte-sized bset-on-memory op on the 68k:
bset.b	#0,AUDIO_DESC+2

But this wasn't doing what I expected.  I tried to verify it by reading it back as the full long-word on the 68k even:

move.l	AUDIO_DESC,d0
btst.l	#8,d0
beq		.skipprint
move.l	#IS_ADPCM_TXT,a0
; Gymnastics to fix up MEMCON1 for Skunk w/CD unit went here
bsr		skunkCONSOLEWRITE

Nothing, the bit wasn't set, and the DSP code concurred.  Strangely, IIRC, this DID work:

ori.b	#1,AUDIO_DESC+2

Am I tripping over some weird alignment requirements or something here?  Not a big deal as I don't even need this code anymore, but I couldn't figure out what was going on, so it bothers me.

dspcode.s

Edited August 5, 2020 by cubanismo
Fix a typo in the code snippets

[+cubanismo]

One other question I forgot to include: @Orion_'s docs say the decoder expects 22KHz audio input: Is that 22000Hz or 22050Hz?  I've been using the latter and it seems OK, but I don't know what I'd be seeing/hearing if it wasn't.  Audio/Video de-sync?  An underrun eventually?

[+CyranoJ]

Not looked at the code, but you can only reliably stop the DSP / GPU interrupts from code INSIDE the interrupt handler, as it is possible for the next interrupt to fire while you are writing the disable command to the registers, thus restarting it again.

[+cubanismo]

I was worried about something like that.  Can this affect bank switching as well?  E.g., can an interrupt come in just as I'm switching register banks and revert back to the prioir bank while clearing the interrupt?  If so, that would imply I can only safely bank switch from an interrupt handler, which would be unfortunate.

[ggn]

10 hours ago, cubanismo said:

-Anyone know what variant of ADPCM IMA encoding avi_ima_encode.exe uses/this decoding code expects?  ffmpeg lists 14, 2 of which (adpcm_ima_qt, adpcm_ima_wav) it can encode.  I started trying to compare the ffmpeg decoders with the DSP code, but figured I could just ask first.  I'm still working on my command-line cinepak conversion tool, and I'd like to pull as many parts of the process into this one tool as possible to simplify things.

 

Are we talking about @Zerosquare's DSP routines as used, for example, here?

 

If yes, after a bit of fiddling I found that the tool sox can create adpcm μlaw samples just fine:

 

sox <input> --channels 1 --bits 8 --encoding mu-law <output.ul> --show-progress rate -v <rate>

 

From what I recall, it's very important for the output file extension to be "ul". Other than that it should be fine. Hope this helps!

[+cubanismo]

Not directly, no.  I'm talking about the DSP routines @Orion_'s CinePak player module contains.  See here:

And just below where @CyranoJ moves to incorporate it into raptor ?

 

Orion claims authorship for this code, though he claims @Zerosquare helped him out with the encoder tool, and mu-law does seem to be one of the bajillion variants of ADPCM encoding, so it's entirely possible they're the same format.  That said, this code uses the term IMA all over the place, and IMA is a different variant of ADPCM than mu-law from my reading.

[Zerosquare]

mulaw (µ-Law, actually) isn't an ADPCM variant; it is a simple non-linear LUT-based coding scheme.

 

I can't find the discussion right now (it was a long time ago!), but I think Orion's ADPCM code was based on the one described in this document:

http://ww1.microchip.com/downloads/en/AppNotes/00643c.pdf

 

 

[Zerosquare]

16 hours ago, cubanismo said:

One other question I forgot to include: @Orion_'s docs say the decoder expects 22KHz audio input: Is that 22000Hz or 22050Hz?  I've been using the latter and it seems OK, but I don't know what I'd be seeing/hearing if it wasn't.  Audio/Video de-sync?  An underrun eventually?

If you're using the JagCD's audio clock (SMODE bit 0 = 0), it's exactly 22050 Hz.

If you're using the Jaguar's audio clock (SMODE bit 0 = 1), the closest rate is about 21869 Hz (with SCLK=18): 26590906 / (2 * 16 * 2 * (18+1)) Hz for NTSC consoles, and 26593900 / (2 * 16 * 2 * (18+1)) Hz for PAL ones.

Edited August 5, 2020 by Zerosquare

[+cubanismo]

On 8/5/2020 at 3:38 PM, Zerosquare said:

If you're using the Jaguar's audio clock (SMODE bit 0 = 1), the closest rate is about 21869 Hz (with SCLK=18): 26590906 / (2 * 16 * 2 * (18+1)) Hz for NTSC consoles, and 26593900 / (2 * 16 * 2 * (18+1)) Hz for PAL ones.

Yes, and the cinepak repacker is responsible for calculating SCLK automatically, as well as an audio drift value the DSP code uses to calculate when it should drop or replay samples (I think it only drops them actually, so I suppose the packer must always round the SCLK value down/clock rate up) to account for disparities.  However, I can't find any code that actually makes the assumption the audio is 22.050k or 22k sample rate in the IMA DSP code, nor any relevant modifications in the 68k harness/player code, so I thought maybe there was some assumption in the avi_ima_encode.exe program.  Are the IMA prediction tables and/or coefficients just tuned for ~22KHz, for example?  If so, it probably doesn't really matter whether I'm using 22000Hz or 22050Hz.

On 8/5/2020 at 11:33 AM, Zerosquare said:

mulaw (µ-Law, actually) isn't an ADPCM variant; it is a simple non-linear LUT-based coding scheme.

 

I can't find the discussion right now (it was a long time ago!), but I think Orion's ADPCM code was based on the one described in this document:

http://ww1.microchip.com/downloads/en/AppNotes/00643c.pdf

 

 

My mistake, my mind confused G.711 and G.722 after mixing beer and Wikipedia.

 

Thanks for digging up the link.  The decoder there does look like a match, and it even includes trivial source for an encoder, so I think I have everything I need to integrate it into some new tools.

 

Now I just need to figure out what's going wrong on the transition from PCM->ADPCM in the merged DSP code.  The interrupts seem to be a red herring: Something just goes wrong near the very end of my PCM track.  Fiddling with the interrupts seems to perturb it, but doesn't seem to be the root of it.  Needs more debugging.

Edited August 7, 2020 by cubanismo
*sigh* I always see the typos right when I'm hitting send

[Zerosquare]

17 hours ago, cubanismo said:

Are the IMA prediction tables and/or coefficients just tuned for ~22KHz, for example?

ADPCM isn't samplerate-sensitive (and even if it was, the ~0.2% difference in samplerate would be too small to matter, anyways).

Edited August 7, 2020 by Zerosquare