This is pretty cool, it's like a Python and *nix version of Exact Audio Copy (EAC) for Windows. I enjoy the ritual of perfectly ripping a CD. I can spend an hour or two scanning the artwork, verifying the track names, performing the rip, losslessly compressing (I prefer FLAC), generating .cue files, checksuming everything, then sitting down to experience the best possible digital copy of a physical item I can self produce.
Years ago, I had most of my music ripped to AAC in iTunes, easily accessible, browsable, and shuffleable.
I now rip each of my CDs to a single FLAC and cue sheet (using XLD on Mac), on the theory that it's the most accurate way to archive a disc. However, I haven't found anything that offers the same accessibility to such a collection as iTunes did. I look through folders, and drag a few cue sheets at a time into Foobar 2000.
I found Swinsian[1] after I ditched iTunes, It works quite good and I’m very happy with it.
While I rip all tracks separately the FAQ states: „Swinsian also supports albums ripped as a single file together with a cue file, and FLAC, Ogg Vorbis and WavPack files with embedded cue information„.
"... on the theory that it's the most accurate way to archive a disc ..."
I won't argue with this but I think there needs to be a qualifier - the most accurate way to archive a disc while using compression ...
Given that an audio cd is encoded in WAV/PCM and we have a WAV file specification, I think ripping to a WAV file remains the gold standard:
"... digital audio extraction software can be used to read CD-DA audio data and store it in files. Common audio file formats for this purpose include WAV and AIFF, which simply preface the LPCM data with a short header ..." [1]
I like the idea that ripping to a WAV file means I never have to rip that disc again.
You can use foobar to index your music files and assign a hotkey to run a search of your music library. I have found that foobar is faster at locating files than browsing my [excessively large] music collection.
Why not use ALAC and individual tracks? It's lossless and compatible with iTunes/Music.app and iOS devices (as well as basically any hardware or software player worth using).
Using whole files rather than individual tracks is just asking for problems with mainstream players in my opinion.
However if you're serious about your music library I recommend Roon. Not cheap but a great solution.
cmus [1] is the closest I found to foobar2000. It is my main music player now, after years of disappointment. It supports FLAC and they claim they support CUE sheets, although I haven't tested your particular scenario. The way I use it is I have all my library in it at once, iTunes style. It has good search & playlists, but no drag&drop, since it's just command line...
For your setup-- if I do original CD -> accrual's rip -> burned CD, does burned CD == original CD for all values of original CD?
I'm mostly thinking of those interstitial lead-in thingies on live and concept albums. E.g., if you let a CD play from track 1 to track 2, there may be 5 seconds of crowd noise leading in to track 2. CD players would show this as track 2 at timing "-5", then count down to zero to get to the actual beginning of track 2.
If the user skipped directly to track two, this interstitial thingy wouldn't be played.
Edit: wording
Also: same question for what.cd ripping process. IIRC they broke the tracks down into different files.
Single file + CUE sheet solves lead-in thingie problem, by storing both timestamps (time when player should start showing 'Track 2', and time which servers as zero for track-relative timestamps)
It pretty much mirrors actual CD structure of TOC (containing all necessary timestamps and metadata) and continuous sequence of frames with audio data
> For your setup-- if I do original CD -> accrual's rip -> burned CD, does burned CD == original CD for all values of original CD?
I was curious about this as well, and the answer was "no". I meticulously followed EAC setup guides for three drives in EAC, I used the recommended gap settings, the results were completely verified by AccurateRip, I was storing the results as a CUE sheet and single WAVE file, all drives would produce the same file, I was using EAC to burn the CUE sheet and WAVE file back to new Verbatim CD-Rs, re-ripping was done with the same setup in EAC, and the files still didn't match. I've been meaning to dig deeper and compare the files in binary, but haven't gotten around to it.
> This is pretty cool, it's like a Python and * nix version of Exact Audio Copy (EAC) for Windows.
And it's now packaged with many Linux distro. At some point it wasn't packaged with Debian and I simply couldn't get it to build so... For a while I ran Fedora on an old PC only to get whipper! Nowadays whipper* ships on even Debian / Devuan so life is good.
It’s also the only tool that private torrent trackers will accept. It’s been rigorously tested and accepted to be pretty much perfect, complete software.
I suggest looking, maybe, at ALAC as well, even though it is generally slept on.
It is open source now just like FLAC, and actually has built-in support in Windows and many Linux music players despite being an Apple format, making it somewhat more universally compatible than FLAC (which isn’t supported in iOS or macOS).
In my school days I was able to add FLAC support to an iPod Touch 4th gen with a quick Cydia module(?) download. I'm skeptical of your claim that macOS doesn't support FLAC. I'm sure mpv and other programs can play it fine. Do you just mean support in the default-installed macOS software? That seems like pretty limiting criteria. I wouldn't expect something like Windows Media Player to cover all that much either.
Storage is cheap, hurray! Another solution: you can archive a music CD using cdrdao and play the result using mplayer.
# $1 = output file
# /dev/sr0 is assumed
cdrdao disk-info
cdrdao read-cd --with-cddb --device /dev/sr0 --read-raw --datafile $1.cdrdao.bin $1.toc
dd conv=swab if=$1.cdrdao.bin of=$1.bin
# To play the BIN: mplayer -demuxer rawaudio BIN"
I'm not an "audiophile" (perfectionist seeker of equipment) but I enjoy listening to classical and (some) jazz compositions and performances as they were conceived, not as "tracks".
Why MP3? It's simply not a great codec to target. If you have a music server, then why not flac? If space is an issue, then why not Opus (which almost everything supports now) or HE-AAC which has nearly as much support as MP3. You can target the same MP3 bitrate and end up with a more transparent encoding. You can decrease the bitrate and have the same quality as your mp3 encode with a smaller bitrate.
I honestly don't understand why mp3 is such a sticky codec. It's long been surpassed by others.
Well, I've done a number of ABX listening tests (apt install abx) and to my chagrin simply could not tell the difference.
I challenge everyone who feels strongly about this to actually bust out abx and do some listening tests comparing flac to LAME-encoded extreme MP3s and prove to yourself that flac matters at all on your equipment. And then share your results with us if you want!
"Why MP3? It's simply not a great codec to target. If you have a music server, then why not flac?"
I still encode to plain old 128k mp3. Here's why ...
First, I keep the WAV originals and those are what I listen to on my music system, in my music server, etc.
Second, if I am using the mp3s it is because I am going to some unknown place to interface with some unknown tool to play these - let's just make life simple and use something that will work everywhere - even the dumb creative audio bluetooth adapter that was in that airbnb that one time ...
Finally, 128k mp3 is typically a 10:1 compression ratio and makes size and space "budgeting" easy. It's easy to remember.
One other thing:
When I export my ripped CD wav collection to mp3 I also compress the filenames - I flatten to ASCII 256 and truncate the filenames to 64 characters, etc. LOTS of car audio interfaces just puke when they hit weird unicode characters or can't display long filenames ... it creates all manner of havoc.
But the whole point of software like whipper or EAC is that they crosscheck your rips with an online DB of rips (and you know, when your rip's checksum match, that it's 100% correct because there's no way you and x other people would have read the same wrong rip, misreading the exact same errors).
As I understand it cdparanoia does not such check. It's "paranoid" by its own but you're not verifying that your rip is 100% perfect.
But then if you then convert it to mp3 and discard the lossless files anyway, I take it you don't care much about data integrity.
whipper and EAC do serve another purpose than cdparanoia (I think, btw, that whipper is something uses cdparanoia under the hood) and I'm pretty sure that people who do care about bitperfect rips do not then go and convert their files to mp3s.
FWIW a .flac file (now a .wav but a .flac: that is lossless and compressed) is about twice the size of a 320 kbps mp3 I think.
Seen that songs are tinier than tiny files compared to modern standards I'm totally fine playing the .flac files I ripped using whipper.
Discovering music in the pre-gap before track 1 was my childhood equivalent of discovering a magickal incantation. In a world before mass use of the Internet, those who knew many of these secrets were our High Priests and Priestesses. I love the ease with which modern music can spread around the world but I miss the opportunity for surprise and discovery.
Every audio CD has a list of tracks with their respective start times, so you can jump to specific songs. The first song also specifies a start time, which does not have to be zero. If it isn’t, the player will skip some of the audio, but you can still reverse back into it.
It’s funny how a CD is more like a tape with contiguous content and an index, rather than a file system.
All of them. Audio CDs subdivide tracks with index marks. They are rarely used for general purpose and few hardware or software players expose index navigation now. However, every track has a lead-in at index 0 and the main program at index 1. When you skip tracks you start playback at N.1. You only hear N.0 when playing through from the previous track. There is no limit to what can be in the lead-in and some discs would hide bonus "tracks" in 1.0 which is often skipped over by hardware players but can be manually navigated to with the index buttons.
There is a commercially available digital format/medium that has higher res than CD? Like, there are 96kHz discs being sold out there? And there are labels out there mastering and producing these discs? Sorry this is news to me! I thought 96kHz encodes were upsamples or homemade rips from analog formats.
Unlike DVDs, CDs don't have sector information. They're just a long continuous spiral of bits, so there is no easy way to tell exactly where on the spiral the head is pointing, especially as many CD players, when you tell them "go to here", will miss slightly.
To compensate for this, data CDs include intermittent data on the spiral that says "you are here", but audio CDs don't do this. The only way to ensure that you haven't either skipped over a piece, or duplicated a piece, is to rip the CD in overlapping chunks, and then compare the overlaps.
The real question is why you'd ever need a bit-perfect copy of an audio CD when CD players never gave bit-perfect playback in the first place and nobody could tell the difference.
Edit: honestly I don't get it. Do you export all raw images from your camera to PNG too? JPG is good enough, and single-pass CD rips are just fine too.
Some CDs are very scratched. Some CDs are CDRs with dye that hasn't aged well. Some CDs just don't read well (poor manufacturing tolerance, perhaps). Some drives silently return bad data on error. Some drives return a lot of errors towards the last tracks even when there is no problem. Drives vary on where they think tracks start and end (generally a uniform offset per drive). Sometimes, reading audio before the claimed start of the CD takes extra trickery. There are many more issues, besides. By ripping multiple times to verify and comparing to a global database of checksums (and in some cases doing error correction), you can be sure of getting exactly the intended audio.
Audio CDs and data CD-ROMs use different encoding modes.
Data CDs have an extra layer of error correction. Audio CDs have less error correction because small bit errors are not a big deal for your listening experience. Most CD players quietly interpolate over small errors in a way that you probably don't even notice.
As early CD players were intended for audio playback, your CD player can lie to the software. It doesn't tell if it's reading at the exact beginning of a sector (because timing information is multiplexed into the audio stream, and some CD players were not byte-exact when interpreting this), and it also doesn't tell you when it silently corrects some errors. Because for a human listening to the audio won't notice.
But of course it makes a difference if you want to make high-fidelity copy.
That's why there always have been copy apps (cdparanoia on Linux, EAC on Windows) that do overlapping reads, and then detect and compensate these problems.
I never understood that either, maybe redbook doesn't have a strict error correction like data CDs have? That's the only thing I can think of but that seems weird though.
Audio CDs have weaker error correction. An audio player has to stream data off the disc without any retries. When a block of data can't be corrected it's passed along with the knowledge that the corruption is localized and usually not noticeable.
This type of ripping, comparing to other rips (paranoia) for bit-for-bit error correction integrity is part of XLD for Mac et al. However, even as a full time audio person, I consider paranoia overkill, and in someways backwards - I want my rip to be my unique rip and not precisely anyone else's - though of course, it most likely is anyway.
You do realise, assuming you ripped to a lossless audio format, your cd rips are 8-12x more accurate than anything streamed of Spotify?
> 8-12x more accurate than anything streamed of Spotify
Maybe in theory. In practice, the difference will be very hard to hear (for most people, in most scenarios). Have you ever done an ABX test to determine whether you would be able to tell the difference between lossless and Spotify's quality?[1]
I did, a while back, and while I was able to tell the difference somewhat reliably for music I knew well (and only for that kind of music), the effort and time I had to spend on finding the minute differences, even with high-end equipment, convinced me that for everyday listening, Spotify was completely fine for me.
>bit-for-bit error correction integrity is part of XLD for Mac et al
AccurateRip is a pretty important feature imo. Like at least I know someone else in the world made a rip which was exactly the same as mine regardless of the optical drive we used. Overkill? Maybe but there is some kind of "safeness" to it
There’s a lengthy explanation in the wiki linked from the github page. But basically cd drives don’t give you a raw stream, and does stuff like error correction.
Well, ddrescue can definitely “read audio tracks” and is perfectly suited for making archival copies of Audio CDs but it sounds like the problem you’re actually trying to solve is interpreting the data as Red Book CD-DA and decoding it into chunks you call files ;)
Why does ddrescue care about "file systems"? Again, I was under the impression that ddrescue does bit by bit copying that I can then mount (and tell it the "filesystem" required).
Is this false?
I have also noticed that, sometimes, ddrescue has trouble ripping dvds, chocking out or producing a low quality rip, that will play perfectly on the same hardware with VLC
Readit News
I now rip each of my CDs to a single FLAC and cue sheet (using XLD on Mac), on the theory that it's the most accurate way to archive a disc. However, I haven't found anything that offers the same accessibility to such a collection as iTunes did. I look through folders, and drag a few cue sheets at a time into Foobar 2000.
Any tips?
While I rip all tracks separately the FAQ states: „Swinsian also supports albums ripped as a single file together with a cue file, and FLAC, Ogg Vorbis and WavPack files with embedded cue information„.
There is a free trial, maybe this works for you.
[1] https://swinsian.com/
https://roonlabs.com/
I won't argue with this but I think there needs to be a qualifier - the most accurate way to archive a disc while using compression ...
Given that an audio cd is encoded in WAV/PCM and we have a WAV file specification, I think ripping to a WAV file remains the gold standard:
"... digital audio extraction software can be used to read CD-DA audio data and store it in files. Common audio file formats for this purpose include WAV and AIFF, which simply preface the LPCM data with a short header ..." [1]
I like the idea that ripping to a WAV file means I never have to rip that disc again.
[1] https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio
It seems like a lot of extra steps to play music but when my library started getting huge it was becoming a pain to organize and sync between devices.
Using whole files rather than individual tracks is just asking for problems with mainstream players in my opinion.
However if you're serious about your music library I recommend Roon. Not cheap but a great solution.
It’s expensive but Roon does this at a level far beyond iTunes: https://roonlabs.com/
[1] https://cmus.github.io/
I'm mostly thinking of those interstitial lead-in thingies on live and concept albums. E.g., if you let a CD play from track 1 to track 2, there may be 5 seconds of crowd noise leading in to track 2. CD players would show this as track 2 at timing "-5", then count down to zero to get to the actual beginning of track 2.
If the user skipped directly to track two, this interstitial thingy wouldn't be played.
Edit: wording
Also: same question for what.cd ripping process. IIRC they broke the tracks down into different files.
It pretty much mirrors actual CD structure of TOC (containing all necessary timestamps and metadata) and continuous sequence of frames with audio data
I was curious about this as well, and the answer was "no". I meticulously followed EAC setup guides for three drives in EAC, I used the recommended gap settings, the results were completely verified by AccurateRip, I was storing the results as a CUE sheet and single WAVE file, all drives would produce the same file, I was using EAC to burn the CUE sheet and WAVE file back to new Verbatim CD-Rs, re-ripping was done with the same setup in EAC, and the files still didn't match. I've been meaning to dig deeper and compare the files in binary, but haven't gotten around to it.
Otherwise, I prefer methods that get me CD->FLAC transfers in a few minutes.
And it's now packaged with many Linux distro. At some point it wasn't packaged with Debian and I simply couldn't get it to build so... For a while I ran Fedora on an old PC only to get whipper! Nowadays whipper* ships on even Debian / Devuan so life is good.
More details here: https://wiki.hydrogenaud.io/index.php?title=Whipper
Or XLD: https://web.archive.org/web/20161123023617/http://whatcdinfo...
It is open source now just like FLAC, and actually has built-in support in Windows and many Linux music players despite being an Apple format, making it somewhat more universally compatible than FLAC (which isn’t supported in iOS or macOS).
I guess it's great to have a *nix tool for the rare occasion of ripping a CD.
Deleted Comment
Extract data to wav:
Compress all wavs to mp3 (in parallel, takes like 1 second, crazy!): Clean up folder Import into mopidy library and lookup/apply metadata with beets (I actually have a bash script for that, obviously)Done. Next step is to go into Mopidy-Iris UI and hit play and it plays all around the house thanks to snapcast. Garsh darn glorious.
https://mopidy.com/ext/iris/
https://mjaggard.github.io/snapcast/
https://beets.readthedocs.io/en/stable/
I honestly don't understand why mp3 is such a sticky codec. It's long been surpassed by others.
I challenge everyone who feels strongly about this to actually bust out abx and do some listening tests comparing flac to LAME-encoded extreme MP3s and prove to yourself that flac matters at all on your equipment. And then share your results with us if you want!
https://manpages.ubuntu.com/manpages/xenial/man1/abx.1.html#...
https://en.wikipedia.org/wiki/ABX_test
But yeah I should put the command to encode to flac there for people who prefer it!
I still encode to plain old 128k mp3. Here's why ...
First, I keep the WAV originals and those are what I listen to on my music system, in my music server, etc.
Second, if I am using the mp3s it is because I am going to some unknown place to interface with some unknown tool to play these - let's just make life simple and use something that will work everywhere - even the dumb creative audio bluetooth adapter that was in that airbnb that one time ...
Finally, 128k mp3 is typically a 10:1 compression ratio and makes size and space "budgeting" easy. It's easy to remember.
One other thing:
When I export my ripped CD wav collection to mp3 I also compress the filenames - I flatten to ASCII 256 and truncate the filenames to 64 characters, etc. LOTS of car audio interfaces just puke when they hit weird unicode characters or can't display long filenames ... it creates all manner of havoc.
As I understand it cdparanoia does not such check. It's "paranoid" by its own but you're not verifying that your rip is 100% perfect.
But then if you then convert it to mp3 and discard the lossless files anyway, I take it you don't care much about data integrity.
whipper and EAC do serve another purpose than cdparanoia (I think, btw, that whipper is something uses cdparanoia under the hood) and I'm pretty sure that people who do care about bitperfect rips do not then go and convert their files to mp3s.
FWIW a .flac file (now a .wav but a .flac: that is lossless and compressed) is about twice the size of a 320 kbps mp3 I think.
Seen that songs are tinier than tiny files compared to modern standards I'm totally fine playing the .flac files I ripped using whipper.
It's both my audio "source" and my backups.
It’s funny how a CD is more like a tape with contiguous content and an index, rather than a file system.
https://en.wikipedia.org/wiki/List_of_albums_with_tracks_hid...
Dead Comment
To compensate for this, data CDs include intermittent data on the spiral that says "you are here", but audio CDs don't do this. The only way to ensure that you haven't either skipped over a piece, or duplicated a piece, is to rip the CD in overlapping chunks, and then compare the overlaps.
Edit: honestly I don't get it. Do you export all raw images from your camera to PNG too? JPG is good enough, and single-pass CD rips are just fine too.
Data CDs have an extra layer of error correction. Audio CDs have less error correction because small bit errors are not a big deal for your listening experience. Most CD players quietly interpolate over small errors in a way that you probably don't even notice.
But of course it makes a difference if you want to make high-fidelity copy.
That's why there always have been copy apps (cdparanoia on Linux, EAC on Windows) that do overlapping reads, and then detect and compensate these problems.
Granted, it's not perfect...
You do realise, assuming you ripped to a lossless audio format, your cd rips are 8-12x more accurate than anything streamed of Spotify?
Maybe in theory. In practice, the difference will be very hard to hear (for most people, in most scenarios). Have you ever done an ABX test to determine whether you would be able to tell the difference between lossless and Spotify's quality?[1]
I did, a while back, and while I was able to tell the difference somewhat reliably for music I knew well (and only for that kind of music), the effort and time I had to spend on finding the minute differences, even with high-end equipment, convinced me that for everyday listening, Spotify was completely fine for me.
[1]: http://abx.digitalfeed.net/spotify-hq.html
AccurateRip is a pretty important feature imo. Like at least I know someone else in the world made a rip which was exactly the same as mine regardless of the optical drive we used. Overkill? Maybe but there is some kind of "safeness" to it
https://wiki.hydrogenaud.io/index.php?title=AccurateRip
How did you calculate a factor by which lossless is better than lossy?
https://pilabor.com/blog/2022/10/audio-cd-ripping-hardware/
It's not meant for copy Audio CDs but CD-ROMs
That's why CDRDAO or CDDA Paranoia exist for decades.
https://web.archive.org/web/20160528213242/https://thomas.ap...
https://www.xiph.org/paranoia/
https://cdrdao.sourceforge.net/
Is this false?
I have also noticed that, sometimes, ddrescue has trouble ripping dvds, chocking out or producing a low quality rip, that will play perfectly on the same hardware with VLC