Created
December 18, 2019 23:54
-
-
Save jjwatt/2eaf0a63fde4bef23acc2b84f8aa83fe to your computer and use it in GitHub Desktop.
Burn Duo-R/PCE-CD/tg16 CD discs in Linux
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#!/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 | |
Hey, this worked perfectly! Thank you!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.