Burn Duo-R/PCE-CD/tg16 CD discs in Linux

burnDuor.bash

#!/usr/bin/env bash

_infile="$1"
_basename="${_infile%%.zip}"
_tocfile="${_basename}".toc

CUECONVERT=cueconvert

unzip -tq "${_infile}" || exit 1
mkdir -p "${_basename}"
cd "${_basename}"
unzip ../"${_infile}"
_cuefile="$(find ./ -iname '*.cue')"
"${CUECONVERT}" -i cue "${_cuefile}" > "${_tocfile}"

# Kind of gnarly sed command
sed -E -i ':a ; $!N ; s/TRACK MODE1_RAW\s+FILE/TRACK MODE1_RAW\nDATAFILE/ ; ta ; P ; D' "${_tocfile}"

cdrdao simulate --driver generic-mmc \
       --swap \
       --speed 16 \
       "${_tocfile}" || exit 1
cdrdao write --driver generic-mmc \
       --swap \
       --speed 16 \
       "${_tocfile}" || exit 1

So, when I originally wrote these without --swap I just heard noise for music tracks. Here's the relevant section of the cdrdao man page that lead me to suspect something like this, in the section about the toc language/file format:

              Audio files may have raw or WAVE format with 16 bits per sample, 44.1 kHz sampling rate,
              stereo. Raw files must have the layout 'MSBLeft  LSBLeft  MSBRight  LSBRight  ...'  (big
              endian byte order). WAVE files are expected to have little endian byte order. The option
              --swap reverses the expected byte order for all raw and WAVE files. Only filenames  with
              a  ".wav"  ending are treated as WAVE files, all other names are assumed to be raw audio
              files. Use tools like sox(1) to convert other file formats to supported formats.

So, either it's misinterpreting these *.bin files as WAV (possibly due to the way the cue file is converted to toc) or it's raw audio data ripped as little endian that cdrdao is assuming is big endian and reversing it normally (when we don't use --swap). Heh. It's the nature of endianness that it's hard to tell, but I should be able to compare my two versions and dig around to find out. I've seen recommendations on forums for PSX and PCE CD-ROM ripping to be done with a similar "reverse" flag (driver flag 0x2 or something in generic-mmc on cdrdao), so it could be that these were ripped in reverse to begin with :).

Oh yeah. I'm guessing these work with emulators and that those way be the main target and not making real physical CDs. Would also be educational to experiment with mednafen and the originals compared with a rip of my build.

SoX is awesome. Gave me a big clue right in the manual.

.cdda, .cdr

‘Red Book’ Compact Disc Digital Audio (raw audio). CDDA has two audio channels formatted as 16-bit signed integers (big endian)at a sample rate of 44.1 kHz. The number of (stereo) samples in each CDDA track is always a multiple of 588.

Looking forward to digging into it more later. I'm beat today.

mystery has been solved. The bin tracks are raw 16-bit CD PCM in le. SoX plays them when I give it the right parameters (no headers, remember? So I have to tell it 2 channels, 16 bit, 48k (44.1)--basically what a CD is). So, in this case, whoever or whatever software ripped these from the CD did the byteswap. It's interesting because the dumpers/archivers who made these think that they're perfect rips ;). They're not if they're byte swapped, ya know? Anyway, so cdrdao assumed that they were in big endian format because that's the RedBook CD Audio spec for raw PCM digital sound, and it just happily burned them without doing the byte swap. Telling cdrdao to --swap is actually doing the right thing and turning them into big endian samples and writing them to the disc.

Hey, this worked perfectly! Thank you!