mooz
Deep Blooper
Posts: 29
|
Post by mooz on May 23, 2020 17:37:59 GMT
For the linux users out there, you can directly replay adpcm data using playHere's an example with the adpcm extracted from a HuVideo of John Madden's Football 4447000000.vox (19.96 KB) . play --rate 16k 4447000000.vox Note that the file must end with the .vox extension. This is because vox files are RAW adpcm files using the OKI encoding ( en.wikipedia.org/wiki/Dialogic_ADPCM ). As you may all know the adpcm decoding on the PC Engine CDROM is performed by ... an OKI MSM5205. OKI adpcm encoding is also supported by the WAV format, but I don't think a lot of players handle it.
The most interesting consequence of all this is that you can encode adpcm samples with sox using:
sox --rate 16k wilhelm.wav wilhelm.vox
|
|
|
Post by dshadoff on May 23, 2020 20:33:56 GMT
Cool stuff !
|
|
|
Post by elmer on May 26, 2020 18:39:35 GMT
The most interesting consequence of all this is that you can encode adpcm samples with sox using: sox --rate 16k wilhelm.wav wilhelm.vox The use of SoX for doing OKI ADPCM conversion for the PCE CD was discussed many years ago on PCEngineFX, and it really isn't a good idea, because SoX has some serious bugs/problems in its ADCPM implementation. On top of that, you really need to read the MSM5205 documentation to understand why the MSM5205 needs a DC-BIAS applied during sample conversion. While the whole of the old thread is a good read for anyone wanting to do ADPCM conversion for the PCE CD, this message explains the fundamental problem with SoX-vs-the-PCE. My post here and the SoX bug-report here show another deep underlying problem with SoX's OKI ADPCM conversion that still hasn't been fixed today.
|
|
|
Post by DarkKobold on May 27, 2020 18:09:33 GMT
The most interesting consequence of all this is that you can encode adpcm samples with sox using: sox --rate 16k wilhelm.wav wilhelm.vox The use of SoX for doing OKI ADPCM conversion for the PCE CD was discussed many years ago on PCEngineFX, and it really isn't a good idea, because SoX has some serious bugs/problems in its ADCPM implementation. On top of that, you really need to read the MSM5205 documentation to understand why the MSM5205 needs a DC-BIAS applied during sample conversion. While the whole of the old thread is a good read for anyone wanting to do ADPCM conversion for the PCE CD, this message explains the fundamental problem with SoX-vs-the-PCE. My post here and the SoX bug-report here show another deep underlying problem with SoX's OKI ADPCM conversion that still hasn't been fixed today.
Did you release your fix? I have 18 wavs I'm converting from WAV to VOX. It'd be interesting to see if there is any improvement.
|
|
|
Post by elmer on May 27, 2020 22:50:04 GMT
Did you release your fix? No, not publicly, because I built the converter with a lot of old source that I can't release. The "beta" version was given to NightWolve (but he ignored it), and SamIAm has used it for some LoX tests. At some point I'll clean up the source so that it can be released and added into the HuC tools directory. In the meantime, here's the Windows "beta 3" version from back in 2016, together with the scribbled notes that I made about downsampling and converting WAV files to get the highest quality. I would recommend that you downsample and dither-to-12-bits using SoX, and then convert the file to PCE/VOX format with my program. Don't forget to add the DC bias when converting from WAV-to-VOX, and to remove it when converting from VOX-to-WAV (as explained in the MSM5205 documentation). Unlike Hudson's original converter, or Dave's old converter (which is an excellent alternative), you don't have to worry too much about clipping with my converter ... in fact I'd actually recommend that you increase the volume and don't worry about having a *small* amount of samples clipped (which the converter will fix), rather than reducing the volume so low that nothing clips, and then you lose dynamic-range. Or you can use a SoX filter to reduce the range. There are lots of options to play with, and absolutely no set of hard-and-fast rules that anyone has come up with, yet.
|
|
|
Post by DarkKobold on May 28, 2020 0:42:28 GMT
Thanks for this. I recorded a 'before' video with the SFX in it. This is a lot more complex than Archaic Pixel's "sox wav -r SR vox" so its gonna take a bit for me to figure out, but I'll at least try and provide some good comparisons for the community.
|
|
|
Post by cmccaff1 on Feb 12, 2021 3:11:45 GMT
To elmer, if you should see this: many thanks for this wonderful converter! I apologize for the necro-bump, but this is of interest to me because I've been learning a lot lately about ADPCM compression. I've had success converting various mp3 files to OKI ADPCM (.vox) with a 'Frankenstein' SOX (14.4.2 + 14.4.0 .mp3 libraries for MP3>WAV conversion, 12.18.1 "sox.exe" for WAV>VOX conversion). The resulting files are smaller than the originals, and depending on sample rate (I stick to between 22.05 and 24 kHz for a good compromise between space and quality) keep most of the fidelity. This is a very useful tool for targeting the MSM5205, a chip with a very fascinating history in itself.
If I'm not mistaken it was the first ADPCM chip ever made, dating all the way back to 1979 according to one source (https://segaretro.org/Pulse-code_modulation). I've written to LAPIS Technology Co., Ltd. (formerly OKI Semiconductor Co., Ltd.) for information regarding when the 5205 was originally released (along with several other chips), but have yet to hear back. The 5205 was a very good chip for its time, and despite its age can still sound good...sadly, many arcade games back in the 1980s made it sound terrible (not just because of the space limitations of the time, but awful samples). It's interesting to learn about what makes it unique from later OKI chips, and wonderful to hear just how good it can sound even nowadays when you account for that uniqueness properly. Thank you for this great piece of software!
-cmccaff1
P.S. On a somewhat unrelated note, I recently learned that the ADPCM-A codec in the YM2610 was actually adapted from the MSM5205 OKI ADPCM codec, right down to having the MSM5205's wrapping behavior! (Many Neo Geo samples took advantage of this, including the "Metal Slug" gunshot.) So in a way, the MSM5205 'lived on' through the YM2610...
|
|
|
Post by turboxray on Feb 13, 2021 6:04:05 GMT
To elmer, if you should see this: many thanks for this wonderful converter! I apologize for the necro-bump, but this is of interest to me because I've been learning a lot lately about ADPCM compression. I've had success converting various mp3 files to OKI ADPCM (.vox) with a 'Frankenstein' SOX (14.4.2 + 14.4.0 .mp3 libraries for MP3>WAV conversion, 12.18.1 "sox.exe" for WAV>VOX conversion). The resulting files are smaller than the originals, and depending on sample rate (I stick to between 22.05 and 24 kHz for a good compromise between space and quality) keep most of the fidelity. This is a very useful tool for targeting the MSM5205, a chip with a very fascinating history in itself. If I'm not mistaken it was the first ADPCM chip ever made, dating all the way back to 1979 according to one source (https://segaretro.org/Pulse-code_modulation). I've written to LAPIS Technology Co., Ltd. (formerly OKI Semiconductor Co., Ltd.) for information regarding when the 5205 was originally released (along with several other chips), but have yet to hear back. The 5205 was a very good chip for its time, and despite its age can still sound good...sadly, many arcade games back in the 1980s made it sound terrible (not just because of the space limitations of the time, but awful samples). It's interesting to learn about what makes it unique from later OKI chips, and wonderful to hear just how good it can sound even nowadays when you account for that uniqueness properly. Thank you for this great piece of software! -cmccaff1 P.S. On a somewhat unrelated note, I recently learned that the ADPCM-A codec in the YM2610 was actually adapted from the MSM5205 OKI ADPCM codec, right down to having the MSM5205's wrapping behavior! (Many Neo Geo samples took advantage of this, including the "Metal Slug" gunshot.) So in a way, the MSM5205 'lived on' through the YM2610... Very nice info! On a side note, the ADPCM chip supports 32khz playback. It's supported in the CDROM BIOS call. It technically might be overclocking the chip, but I think that was just speculation (nothing confirmed).
|
|
|
Post by dshadoff on Feb 13, 2021 17:48:46 GMT
It doesn't overclock the chip, but it runs out of memory very quickly, and refilling the ADPCM buffer has to come from somewhere like main memory (which is also limited).
|
|
|
Post by turboxray on Feb 13, 2021 22:09:38 GMT
It doesn't overclock the chip, but it runs out of memory very quickly, and refilling the ADPCM buffer has to come from somewhere like main memory (which is also limited). There's also the auto DMA stream mode from the CD data track for ADPCM playback. The only thing the cpu does is switch the pointer - the MCU on the CD unit side continuously fills in the ADPCM ram for you.
|
|
|
Post by dshadoff on Feb 13, 2021 23:32:57 GMT
While this might sound appealing, in practice it means that you can't be playing CD-quality music during that period... and 32KHz monaural 5-bit ADPCM is not as good as stereo 44KHz 16-bit sound...
|
|
|
Post by turboxray on Feb 14, 2021 22:27:43 GMT
It accumulates to 12bits and outputs the top 10bits, so it's pretty decent quality at 32khz. And that's like less than 1/5 the size of CD audio, so more room for dialog or such in game. 70+ minutes sounds like a lot of CD audio, until you start piling on audio tracks haha. We ran up against this limitation with the Raiden SCD hack.
|
|
|
Post by dshadoff on Feb 14, 2021 23:10:07 GMT
Fair enough - you could store more ADPCM on a CDROM if that's the case.
|
|
|
Post by cmccaff1 on Feb 15, 2021 3:03:57 GMT
Thank you for the replies! It is great to learn more about the 5205...I do remember reading somewhere that with overclocking the chip can reach a maximum sample rate of 32 kHz (at least with how it's implemented in the PCE). I'm not sure if 32 kHz can be achieved on arcade hardware (I've never seen it used above 8 kHz in any arcade titles), but that's insanely impressive for a 40+ year old chip. An old arcade game from the late 80s, "Born to Fight", uses four 5205 chips controlled with a sample player. Along with the game that inspired it (Operation Wolf), it is an example of high-quality sampling on the 5205.
Several years ago on YouTube, a user named Adam Wordsworth posted a video featuring something known as the OKI SAS 1A Voice Memory Processor (https://www.youtube.com/watch?v=b_MvA4-Hm_I). It appears to have been designed specifically for use with the 5205, but should be compatible with later OKI chips too. I posted a comment asking Adam how he ended up acquiring it, and have yet to hear back (at this point I'm not expecting a response, but anything is possible). The SAS 1 and 1A seem to be quite rare now, as I've never seen either turn up for sale online. They could be of great use for arcade and PCE programmers, if one can be found in working order.
-cmccaff1
|
|
|
Post by elmer on Oct 27, 2021 17:27:39 GMT
Did you release your fix? No, not publicly, because I built the converter with a lot of old source that I can't release. At some point I'll clean up the source so that it can be released and added into the HuC tools directory. Well, I *finally* cleaned-up my ADPCM converter to remove the proprietary stuff that I can't release, and to fix some of the worst examples of the awful old coding-standards that I used to use ... and the source is now checked into my HuC project on github. It is still grossly over-complicated due to its evolution from a tool that was designed to handle a number of different types of WAV file encodings, and different output formats, but heck ... it works! I still need to add some usage-notes and PCE tips, but it's there if anyone wants it. Enjoy!
|
|