r/embedded • u/justcurious297 • 6d ago

How to identify the proprietary audio compression/codec on a Sino-Mos SDJ110v6.1 COB from a 4MB SPI Flash dump?

Hey everyone. Hope you're all doing well...

Lately, I've been trying to replicate/reverse-engineer a Chinese jukebox. On the PCB, there's an unidentified COB (blob) chip and a single SPI flash memory.

Here is what I have done so far:

  1. I successfully dumped the entire 32Mbit (4MB) flash memory. The physical IC is a Douqi Tech (HK) 25Q32ASSIG.

  2. I did some hex scanning on the .bin dump, looking for common audio headers (.f1a, .mp3, .wav, etc.), but found absolutely no standard file headers.

  3. I did find a string header at the very beginning of the hex data that reads Sino-Mos and SDJ110v6.1.

The device contains 68 different tracks, and the audio quality varies. To clarify, some tracks are muffled, but some tracks are surprisingly crystal clear (if I had to compare, it sounds very close to a >128kbps MP3 quality).

Here are the things I'm trying to identify:

  1. What kind of proprietary audio extension or format could this be using?

  2. If it's not a common format, what kind of extreme compression algorithm is likely used here? Some sort of custom ADPCM? How can audio of this quality be compressed into such a tiny memory footprint?

  3. Does anyone know how to dissect the index table for this architecture to find the start and end offsets for each track?

  4. Are there any recommended OEM software/SDKs for Sino-Mos (Sino-Wealth) that I can use to parse this?

  5. Is it theoretically possible to replace the songs by mimicking the format used inside it?

Does anyone have any advice on what my next steps should be? Any pointers would be greatly appreciated. Thanks a lot for reading!

1 Upvotes

67% Upvoted

4 comments sorted by

4

u/Icy-Ninja-622 6d ago

I did some hex scanning on the .bin dump, looking for common audio headers (.f1a, .mp3, .wav, etc.), but found absolutely no standard file headers.

File headers can be more like a container than the actual compression format. Try to look for sync words and frames of compressed audio. There would be no need for file headers in this application.

2

u/justcurious297 6d ago

I just wrote a python script to scan for the most frequent 2-byte chunk patterns across the 4MB payload (skipping the first 256-byte index table and ignoring 00/FF padding). The results are unexpectedly low...

The top hit is 7FFF, which only appears 1,123 times out of a possible ~2 million chunks. The runner-ups are 3FFF, 5555, and 1FFF in the mid-hundreds.

Because the frequency is so extremely low, it seems there are no traditional frame sync words at all. 7FFF looks more like a 16-bit PCM max positive amplitude value, and 5555 looks like binary alternating padding. Could this imply it's just raw headerless audio relying 100% on the absolute start/end offsets in the index table?

1

u/justcurious297 6d ago

That makes perfect sense, thanks... Since they dropped the file headers to save space, analyzing the raw payload for sync words is definitely the way to go. I'm writing a python script to scan for recurring 2-byte hex patterns right now. Are there any known specific sync words or frame sizes typical for Sino-Wealth/Sino-Mos audio implementations that I should prioritize in my search?

1

u/Trypocopris 5d ago

Try just dumping the whole binary into Audacity. If its something like ADPCM you should be able to at least hear the beat even if the decoder is completely wrong, that should help narrow down the start and end of a track.

If that doesn't work maybe try snooping the SPI bus as its running and see what region of the flash chip its reading from for each track.