Whipper: Accurate Audio CD Ripping | Hacker News Reader

Whipper: Accurate Audio CD Ripping

github.com

266 pointscatseyechandra209 comments

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.

Brings back similar memories for me as well :)

I guess it's great to have a *nix tool for the rare occasion of ripping a CD.

Linux has cdparanoia for decades now, which doea all that stuff and I'm not sure what's new about Whipper.

Whipper uses cdparanoia under the hood, but it adds features like metadata fetching, gap detection, and so forth.

More details here: https://wiki.hydrogenaud.io/index.php?title=Whipper

I remember tools such as Asunder and grip adding passable GUIs around cdparanoia.

Always makes me sad remembering what was lost when What.CD went offline.

Oink.

And Oink before it. But the torch has been passed to the next community, not all has been lost

Woah Oink. I had forgotten what it was called, but I learned so much about digital quality and was exposed to so much new music that I still listen to today.

The pink palace! I miss it.

While not all has been lost, I strongly feel that every time the community migrates from one platform to another, the long tail of small time users gets cut off. Ties are severed, people fall out of reach, etc. I initially joined a few sites that popped up after What, but since I didn't find any of the users there that I used to talk to regularly, I don't visit much ever anymore.

Not only that, it’s almost a certainty that not every little rarity alike to ‘bootleg of local ska band from the 80s that never released an album’ makes the jump each time.

Of course, those are mostly oddities that virtually no one cares about in a sonic sense, but it’s still a piece of musical history.

Kind of makes me wish whoever sued what.cd offered them a sort of clemency deal: keep the site up until everything has been archived by a legit third party (that wouldn’t share it, but so everything has at least been preserved), then shut it down.

Instead they burned down the musical library of Alexandria..

I miss OiNK all the time. So much music that wasn’t available anywhere else. Sigh.

And oink, waffles, Pedro's. It was the golden age of piracy.

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

Cdrdao preserves all lead-in data for rips in DAO mode. I split tracks to separate files with lead-in of the following track included at the end. Combined with Lame's gapless encoding support you can have seamless playback of CDs that blend tracks.

> 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.

Depends. AFAIK subchannels are not dumped verbatim, so things like CD-TEXT and CD+G images or toc/timing hacks may get lost or mangled.

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.

Any tips?

Hard drive space is cheap. Do both.

hate to say, but this is my way... EAC to flac and leave it on a NAS, then XLD to apple lossless on my macbook and sync to my iPhone... working great for me so far

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„.

There is a free trial, maybe this works for you.

[1] https://swinsian.com/

Very promising: supports macOS 10.8 and later, last updated in 2021, and it read my whole CD collection in just a couple of minutes. Thank you for the suggestion.

I wonder if it's still being developed. It's concerning that it's still an Intel-only build instead of a Universal build that can run natively on Apple Silicon hardware.

I recently contacted the developer about this. He replied that the only reason he hasn’t released a native Apple Silicon build is that he doesn’t have an Apple silicon Mac yet. I was tempted to fund raise and send him one!

My understanding is one can build a Universal app on either platform. Debugging the Apple Silicon side does require an Apple Silicon Mac but a well-developed app with a constrained feature set might "just work." They could make a Universal build and offer it as a beta to those who wish to try.

I don't know where they're located but a refurbished Mac mini from Apple is $589. AWS EC2 M1 Mac instances are ~$16/day ($0.65/hour, 24-hour minimum).

https://www.apple.com/shop/product/FGNR3LL/A/refurbished-mac...

https://aws.amazon.com/about-aws/whats-new/2022/07/general-a...

https://aws.amazon.com/ec2/dedicated-hosts/pricing/#On-Deman...

The developer is regularly putting out beta releases [1] for the 3.0; With the other comments I found, I assume it's a single person development - probably in spare time - and only using an Intel mac.

[1] https://www.swinsian.com/sparkle_beta/sparklecast.xml

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.

You rip one CD to one unsplit FLAC file? I use EAC to rip each track to FLAC with a cue sheet for the CD and Plex to play it.

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.

"... 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.

[1] https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio

FLAC is lossless, so there shouldn't be any difference in accuracy between the WAV and the FLAC. Of course, this is why people often choose FLAC for archival of ripped CDs.

Edit: I only mention this because I can't think why the extra "while using compression" qualifier is relevant except for information loss during compression.

FLAC is lossless. Any audio CD ripped and encoded to FLAC will be the exact same accuracy as WAV.

Does FLAC preserve the exact bytestream of the CD tracks? (As an analogy, PNG is "lossless," but it won't natively preserve the metadata of a raw digital camera image.) The audio will be preserved but there might be interesting details on the CD like easter eggs, copyright text, etc. and I'm not sure FLAC would capture those.

> Does FLAC preserve the exact bytestream of the CD tracks? (As an analogy, PNG is "lossless," but it won't natively preserve the metadata of a raw digital camera image.)

No, but if that is the definition being used, neither does WAV store that data either.

> The audio will be preserved but there might be interesting details on the CD like easter eggs, copyright text, etc. and I'm not sure FLAC would capture those.

Flac does allow for storing a lot of metadata in the flac file itself, including: CUE sheet, a picture (image file), and arbitrary tags (key value pairs). So much of those could be stored in the flac file, but obtaining them (Easter eggs and the like) is dependent upon the program ripping the CD, not the file format storing the result of the rip (flac does not do CD ripping itself).

> No, but if that is the definition being used, neither does WAV store that data either.

I meant versus a raw binary dump of the CD.

Audio CDs have less error correction than CD-ROMs. When you rip an audio CD, the drive is doing the error correction, and may give you PCM data different from what was written on it. Software like ExactAudioCopy tries the best it can, but that’s exactly that. Reading CD-ROM data is different. You can get an iso image of a data cd, but not an audio one.

This was done to both increase play time and discourage copying.

So since you’ll never get the raw redbook data off a cd, there is no reason to prefer WAV over FLAC for CD audio.

> This was done to both increase play time and discourage copying.

I doubt copying figured into the decision process (at least not a deliberate "anti-piracy" thought process).

The CD was released in 1982 [1]. This was only one year after IBM had released the original IBM PC, which came with one or two 320KB 5.25 inch floppy drives. The IBM PC did not have an official "hard drive" variant from IBM until the PC XT [3] released in 1983 (one year after the CD) and the hard drive option was a whole 10MB. When the target was replacement of the Vinyl LP player and compact cassette deck, and when their target customer base might have had 10-20MB of total storage in their personal computers (if they even had a personal computer), it would seem unbelievable to Sony and Phillips that those customers might even be capable of copying a disk holding somewhere upwards of 850-950MB of digital audio data.

And of course in the above I am overlooking that in order to "copy a CD" (as in make a digital copy) one first requires a CD drive that can interface with a PC in a digital way, and such drives did not appear until some years after the CD's release.

So with an amount of data on each disk that exceeds end users available storage by orders of magnitude, and no "CD drives interfaced digitally to computers" at the same time it seems unlikely that Sony or Phillips ever even considered that end users would be able to digitally copy CD disks.

[1] https://en.wikipedia.org/wiki/CD_audio

[2] https://en.wikipedia.org/wiki/IBM_Personal_Computer

[3] https://en.wikipedia.org/wiki/IBM_Personal_Computer_XT

I found that some Easter eggs weren't archived by EAC due to the fact they subly broke the CD spec. An example would be the first song of some versions of White Ladder by David Gray have a song "before" the first song. You press play then press "rewind" and the timer goes to -0:01 ... -3:45 or whatever and a song plays before the regular song at 0:00. I was tricky to hear it with a CD player because the rewind behavior was kind of undefined.

https://eeggs.com/items/8745.html

An audio CD can be done in a way that your wav will not represent the full data on the disc. If you want an exact copy, you need to do a disc image with preserve empty space or something similar. The CD can contain both audio tracks and data tracks. Some audio tracks can be hidden from normal play and a ripper might miss those too.

So if you really want to save an exact copy of the CD, you will have to find something better than wav to save the data. There are a few programs that can do an image to ISO format, that might be what you want. I guess it's a bit harder to find a player that can handle the audio tracks from an ISO though.

(Memory is a bit vague on formats and names but this is the general idea.)

,ISO can't store Audio CD at all.

I've done a little bit of testing with flac and wav files. It is actually possible to convert a flac file back into an identical, bit exact wav file.

Roon. The commentary is invaluable and links to related music.

I use Roon and love love love it

https://roonlabs.com/

There are dozens of us

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...

[1] https://cmus.github.io/

I did the same - ripped all my albums to iTunes but after it slowly became more unpleasant to use for my use case I moved to Roon.

It’s expensive but Roon does this at a level far beyond iTunes: https://roonlabs.com/

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.

I think it's great when the artists sell me a complete FLAC of their album, so I don't need to do any of that.

Otherwise, I prefer methods that get me CD->FLAC transfers in a few minutes.

I no longer buy CD's, but all that we have in the house have been converted to FLAC and put in the cloud / multiple places.

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.

I’m talking about stock macOS, yes.

> something like Windows Media Player to cover all that much either

Well, in Windows 11, Windows Media Player does support ALAC. Heck, it will even rip your CDs and encode them in ALAC.

Just in case anyone was wondering, EAC works without a hitch with WINE on Linux.

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.

Orpheus will rate appropriate XLD and whipper logs as 100% fwiw

Also I could be wrong, but don't most trackers still accept rips that they consider inferior, but then they could be trumped by someone else that made an EAC rip?

From my experience an XLD rip can be equal to an EAC rip in terms of rating on the site (RED and OPS). I've always been ripping this way and always had a perfect score; It's not easy though. There is a lot of nuances that influence the score, so you need to do a lot of reading and checking.

Highly recommended for anyone using EAC (from a mirror of the what.cd wiki): https://web.archive.org/web/20161123061955/http://whatcdinfo..., https://web.archive.org/web/20161123062018/http://whatcdinfo...

Or XLD: https://web.archive.org/web/20161123023617/http://whatcdinfo...

> 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.

Do you do anything to handle "hidden tracks" (i.e. the last track has some audio, then some silence, and then some more audio)?

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".

That's a nice package. I use some of the components on the command line to get my CD data to the music server.

Extract data to wav:

    cdparanoia -B

Compress all wavs to mp3 (in parallel, takes like 1 second, crazy!):

    parallel lame --preset extreme {} -o {.}.mp3 ::: *.wav

Clean up folder

    rm *.wav

Import into mopidy library and lookup/apply metadata with beets

    beet import .
    sudo su - mopidy -s /bin/bash -c 'mopidy --config /etc/mopidy/mopidy.conf local scan'

(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/

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!

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!

The commenter suggested not only FLAC but also Opus, which is a lossy codec that compresses better than MP3. So you could save some disk space.

But generally I agree with you, if you're happy with how your setup works and sounds, MP3 is no great sin.

As for what the commenter said, firstly, MP3 was synonymous with digital music in most of our minds for so long; second, even if modern equipment handles all the better codecs, a lot of us still have memories of times it didn't in the past. Third, I think some of the tooling around metadata is not as developed or ubiquitous for, say, an ogg container. There are ogg comments, but ID3 is better supported.

> MP3 was synonymous with digital music in most of our minds for so long

I think this is probably the main reason for mp3's stickiness.

> second, even if modern equipment handles all the better codecs, a lot of us still have memories of times it didn't in the past.

Sure, and your dvd players didn't always handle x264. Things change :). It's been probably 10 years since new audio hardware had trouble with non-mp3 media.

> Third, I think some of the tooling around metadata is not as developed or ubiquitous for, say, an ogg container. There are ogg comments, but ID3 is better supported.

Granted, I think ogg will have worse support for equipment. However, I'd expect that aac in m4a will end up with the same level of support as mp3s do today simply because it's a lot more common than opus (and older).

> MP3 is no great sin.

It's not, I just don't like seeing generally superior tech getting sidelined because the inferior tech is more familiar. Perhaps that's a sin on my part :). I admit it probably doesn't ultimately matter if your music is 1MB vs 2MB.

I've written code to parse metadata out of an M4A. I'm sure Apple does a good job of it given they've done that in iTunes for 20+ years, but it's a lot less documented and straightforward than ID3v2, as imperfect and hacky as that format is. As a result, I can pretty trivially edit ID3 from a shell script, but dealing with M4A metadata still feels like a black box.

(After typing that, I realize that calling it a "black box" is a pretty good pun on MP4 box formats..)

My car's radio supports both MP3 and AAC-in-MPEG4, but with the latter it occasionally has trouble reading the metadata, though I haven't really figured out why exactly that might be.

I don't disagree that given a high enough bitrate, MP3 will become transparent. More my point was why not use a more efficient codec (like opus) if you are trying to save bits (128kbps is transparent for stereo music vs the 200+kbps for lame extreme).

If you aren't trying to save bits, then why use a lossy codec at all?

That's more my point. MP3s will be smaller than flac, for sure, but opus or he-aac files can be even smaller (half the size or more).

Ah yes all that's a fair point. I guess I just am stuck in the old LAME is best mentality of the olden days. I will look into opus. Thanks.

The dinamics of mp3 is much lower.

It depends on what audio setup you do the listening. On laptop speakeakers it will be no difference.

I did an abx test on reasonable caliber headphones. Try it! It surprised me.

"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.

I'm really sorry for dogpiling on your setup here, but why keep wav files rather than flac? Flac files are lossless compression, so you can always get the exact same wav out of them, they take less disk space and they can hold Metadata. Flac support is also really common these days.

The only argument I’ve heard that makes me go “OK, fine!” in favor of FLAC is that they forced a standardization of metadata.

FLAC is well-supported. But, PCM RIFF WAV files are triv-i-al. Any CS101 student can write a parser. They don’t need decoding.

2:1 lossless compression is nice. It’s quite a technical feat.

Meanwhile, as an old software engineer, I focus pretty hard on technical simplicity. And, the complexity ratio of PCM vs. pretty much else everything is a a very, very small number. Very small :p

If enough time or technology has passed that someone has to write a wav parser, how do you expect them to mount your file system, assuming it has survived?

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.

It's both my audio "source" and my backups.

Ok that's a good argument. I downloaded whipper and tried it out on a few CDs. So far so good. Flac and exact copies, here I come!

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.

Wait what? How does this work? Which CDs had music stored before the start of the first track?

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.

https://en.wikipedia.org/wiki/List_of_albums_with_tracks_hid...

WHAT THE FUCK

I bought hundreds of CDs from 1990 through to about 2005, some of them on that list, and I never had a clue about this technique.

I knew about hidden tracks at the end after a silent gap - e.g. Nevermind had a hidden track after 10 minutes of silence at the end, was fun to schedule it on a CD jukebox in a bar...

It's actually more like an analog record than a tape. It's even layout in a spiral (instead of circles, like for a DVD, or like tracks on a floppy or harddisk).

"Blumenkraft" by OTT, but only on the CD, not the download from https://ottsonic.bandcamp.com

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.

I love how this software would have been legend in the 90s/00s but now you are just a weird audiophile nerd for messing around with physical CDs.

In the 00s you just used Exact Audio Copy

Still used in Russia constantly. It's the gold standard.

Audiophile nerds have moved on to digital formats that are much higher res than CD or have gone 100% analog.

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.

Aac on an SSD or on the internet?

Most hi-res audio is being sold as digital downloads. I don't think there's a currently-sold physical medium that contains digital data that's higher quality than a CD.

SACD (DSD format) is higher than CD but still not as high as 24/96k available on sites like Qobuz.

SACD, HD-Audio, Blu-Ray Audio.

I own music only discs in each of these formats. I think the last Blu-Ray Audio disk I bought (Yello Point Dolby Atmos release) was shipped in 2021.

Granted, they are fairly sparse. That disc was an import.

Yes, obviously, its called SACD and its a couple of decades old. Even DAT is better than cd, if you're only comparing sampling rate. https://en.m.wikipedia.org/wiki/Super_Audio_CD

Also DVD-Audio, https://en.m.wikipedia.org/wiki/DVD-Audio.

We just used cdparanoia back then (on Linux, on Windows you used EAC). Actually, this Python app uses the cdparanoia library for the ripping itself.

So why would ripping CDs result in less than perfect copies - I thought digital information would almost always be read correctly?

I read the linked rationale and still don’t understand why this is even a problem.

Transferring from disc to system via a laser is analogue and error prone. What if there is a scratch? What if the cd wobbles?

That's what the CRC is for.

Granted, it's not perfect...

But then the CD should skip right or reread the bits - maybe it doesn't maybe it guesses to keep the music playing...

And I guess that's why cdparanoia exists - to put hyper-focus on those edge cases and get them right. I used to use it to rip in the 90s or early 2000s but never looked deeply into how it works.

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.

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.

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.

I mean, that's literally what RAW files from cameras are, and there are uses for them. I don't know if a multi pass CD rip is quite as useful as a RAW image, but your analogy is not as strong as you think it is.

So you archive RAWs, not just JPEGs? I get that professional photographers do, but I never would. And I think they do it to preserve byte depth or whatever, but FLAC from a single pass CD rip has all the bit depth of the original, even if it has a few bits wrong you'll never notice it.

I mean I do keep the RAWs but the use case there is a bit different anyways, even the JPEGs aren't a simple matter of "the compressed version" it's also "the preprocessed version". OTOH it takes no more storage to back a CD up correctly vs incorrectly so why be keen to add a generation of loss? You can lower the quality whenever you like but you can never add it back.

> 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.

No, i keep them in RAW and develop a few for albums and print and such.. No, JPGs and PNGs are not good enough, the loss is REAL when you try to actually develop the picture.

I must admit I _REALLY_ don't get this "good enough" mentality.. Like.. Here's this way to get a more precise representation of the music you bought, and you'll go "nah, that's not for me, I prefer whatever random data I happen to get on the first go".. for what? why ?

If you really want to have a different product on every playback, I guess vinyl is the way to go :P

> I must admit I _REALLY_ don't get this "good enough" mentality.. Like.. Here's this way to get a more precise representation of the music you bought, and you'll go "nah, that's not for me, I prefer whatever random data I happen to get on the first go".. for what? why ?

The purpose of music is to be perceived. There is no perceptible difference, therefore there is no difference. CD Paranoia/etc are a waste of time, these tools make ripping a CD take several times as long for no tangible benefit.

> There is no perceptible difference

This is often not the case. We're not talking about subtle interpolation differences. Depending on the drive, and the disc, bad rips can be full of music skips, clicks, and pops. It's really annoying to find this out days later after you ripped something. Better to get it right first time.

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 remember back in the day using https://xiph.org/paranoia/ for ripping. Tons of burned cds that eventually were tossed in favor of Spotify.

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?

>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

https://wiki.hydrogenaud.io/index.php?title=AccurateRip

My audio now is usually played via AirPods. So any lossless rip is lost on me since it’s compressed anyway.

But you could avoid it being compressed twice, which can introduce additional artifacts.

>your cd rips are 8-12x more accurate than anything streamed of Spotify?

How did you calculate a factor by which lossless is better than lossy?

>your cd rips are 8-12x more accurate than anything streamed of Spotify?...

>...How did you calculate a factor by which lossless is better than lossy?

I specifically typed accurate, not better.

>your cd rips are 8-12x more accurate than anything streamed of Spotify?...

>...How did you calculate a factor by which lossless is better than lossy?

>I specifically typed accurate, not better.

Yeah OK, that's just wording. Which two factors did you specifically compare, that gave you the 8-12x figure?

The 'two factors' are not two factors. Frequency range, bit depth, and whatever lossy algorithm is used, all play a role. A lossless rip matches the original audio as stored on the CD. A lossy rip will commonly 'lose' between 8-12x of that information. Lossy audio, like mp3 and m4a, 'throw away' information that is otherwise maintained in a lossless audio file. Hearing the difference is not being questioned, but the integrity.

Oh OK, so you're specifically talking about bitrate difference. I wouldn't agree that that 8x higher bitrate means the file is 8x more accurate, but I get your point now.

You continue to misrepresent my responses. Are you trolling? I did not say and was not 'specifically talking about bitrate difference'. Frequency range, bit depth, and whatever lossy algorithm is used, all play a role, is plain to see.

> 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

You make a valid point, except I really did mean to and did type 'accurate' and not sound quality. I do concur with your example of how they can sound the same compared with lossy.

Here is a sortable and filterable drive accuracy listing and more information about audio cd ripping:

https://pilabor.com/blog/2022/10/audio-cd-ripping-hardware/

Can someone explain to me why this is needed vs an imagining tool (say ddrescue)? Is there no tool that actually makes a bit perfect copy yet?

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.

So the error are used to trip traditional tools like ddrescue like in the days of old?

The drive itself abstracts out the raw stream if I understood things correctly. Similar to how a PC floppy controller can’t do a low level disk image, because it does some interpretation of the signal before handing it over to the system.

One example mentioned was that drives generally don’t read the precise samples you ask for. https://web.archive.org/web/20160528213242/https://thomas.ap...

ddrescue can't read audio tracks, Audio CDs doesn't have a file system in the traditional sense either etc.

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/

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

ddrescue works with blocks and bytes. Audio cds are different. They contain a single physical bit stream interpreted as several interleaved logical bit streams representing e.g. audio, position, metadata, error correction. They are not a sequence of bytes. Cdroms and dvds put a block and byte abstraction on top of this so ddrescue can do something with them.

Good for personal use, but in the scene you must use a recent enough version of EAC or XLD.

Orpheus allows whipper and gives it the same rating as EAC and XLD when the cache is defeated fwiw

My go-to audio CD ripper is this: https://www.exactaudiocopy.de/

Agreed. I mean, great that people make alternatives, but this was a solved problem long ago. Also EAC is a lots more user friendly that some python software.

> Also EAC is a lots more user friendly that some python software.

User friendly is a matter of opinion.

My go-to CD ripper is https://github.com/cyanreg/cyanrip

I only discovered Cyanrip somehow quite recently and rate it as highly as Whipper, which I've used since its Morituri days. Appreciate Cyanrip's desire to be suckless but still enjoy Whipper being able to produce TOC/CUE sheets. MKTOC can always prove handy too if one cares about Right Offsets..

Somewhat related question: what's the gold standard for organizing ripped music, ideally with some sort of metadata lookup? Ever since Google Music shut down, I have my exported music in a folder, but it's badly organized and with duplicates. Too daunting a task for me to do manually - especially because some of the id3 tags somehow got messed up.

Picard has worked really well for me.

https://picard.musicbrainz.org/

You could check out https://beets.io/

Roon.

That will be a contentious subject, there really is no golden standard. I subscribe to The QF Bible personally, and I have configured Picard as such (feel free to ask how if you're interested) https://musichoarders.xyz/reference/bibles/the-qf-bible/

Since this is just python code, it should run on Windows and MacOS also. Just compile to a static executable and be done with it.

The project has external dependencies including dynamic libs that you cannot just compile to run on Windows and Mac.

The readme says:

- Detects and rips _non digitally silent_ [Hidden Track One Audio](http://wiki.hydrogenaud.io/index.php?title=HTOA) (HTOA)

It's unclear how this is used -- is it for secret data or is it for hidden music?

Hidden music. Some albums[1] have hidden tracks.[2]

[1]: https://en.wikipedia.org/wiki/List_of_albums_with_tracks_hid... [2]: https://en.wikipedia.org/wiki/Hidden_track

For audio geek who wants a high quality audio extraction from their CD collection

Thank you Chat GPT

I have noticed a lot of super low-effort comments like this recently. They typically don't even write as well as current-gen chatbots.

Fyi this is just the OP adding a description

Why would I use this over abcde, another cdparanoia frontend that is packaged for every major distro?

I second this question. I've used both before; the user experience is basically the same, and there's no audible difference between the two.

My understanding is whipper is more paranoid than abcde. whipper does a couple things to ensure a perfect rip:

* Rips tracks twice and ensures the checksums match (retrying if they do not)

* Compares the track checksums against the AccurateRip database

I think this gives much more confidence that the result is correct. The tags seem a lot more detailed with whipper too.

What I appreciated most about 'abcde' was that just prior to the rip it would open up the CDDB output in 'vim' and allow quick and easy edits to what are, sometimes, horrific titling and track entries ...

It's a very nice workflow and avoids a lot of cleanup ...

Ooo, I can finally get a bit-perfect copy of "Teenage Wasteland"? Rad.

Nice

Very recently decided to try getting off Spotify, so I'm in the CD-ripping workflow lately, after about 10 years off. (Also buying a bunch of direct download albums off Bandcamp.)

I like to think it's a trend?

Been using Asunder to rip, encoding as FLAC with max compression.

Playing back usually with Amarok but it's buggy for me these days so I'm not satisfied. Rhythmbox is good, too, but failed me by not inhibiting sleep during playback. I don't have a really solid go-to music organization / playback app right now but open to suggestions.

Can anyone recommend a (currently market available) USB drive that produces good results? Back in the good old times I had a Yamaha CRW F1 which many still say was the best for accurate rips, as it supported many advanced modes required to read even scratched CDs better than others.

From the dBpoweramp CD Ripper forums, "CD Drive Accuracy 2019": https://forum.dbpoweramp.com/showthread.php?43786-CD-Drive-A...

Also mentioned elsewhere in this thread: https://pilabor.com/blog/2022/10/audio-cd-ripping-hardware/

I have a very old CD collection I hadn’t looked at in years that I recently started ripping. Happened upon a tool called cyanrip and it works perfectly for me. Automatically downloads the art too and everything. Anyway it checks all the boxes for me and I haven’t looked back.

This utility used to work wonders, too. Should still work despite what looks like the author moving on: https://github.com/blabber/ripit

Whipper is great and I use it to backup my audio CDs in FLAC format. There's a plugin called whipper-plugin-eaclogger which will generate the logs in a format compatible with EAC.

Then just run whipper with: `whipper cd rip -L eac`

That won't create a file that will make it pass the logcheck, just so you know.

I haven't needed to solve this problem since somewhere around 2003 but my tool used to be CDex https://cdex.mu/screenshots

Let me guess—It really whips the llama's ass.

What is an audio CD and where do you stick it?

>Docker

Maybe it's just me but when I see Docker with a project like this I already zone out. This is still just based on cdparanoia/cdrdao [0]. I wish people would just push single portable binaries instead of starting the whole process with Docker (especially when the source code is alreaedy available)

0, https://github.com/whipper-team/whipper/blob/develop/whipper...

I agree with you, however if I had to pick between snap and docker I would go with docker evertime.

Docker is a life saver if your shipping software on Linux. Otherwise you’re going to have to deal with endless bug reports from oddball distros. Docker lets you test with a stable set of dependencies and know that’s what your users will see.

It's like people forget statically compiled binaries exist

It's a good solution, but there are popular programming languages where that doesn't work.

How about flatpak? To fulfil this function?

And snap, Appimage...

AppImage is just a handy single-file solution for the very standard "tarball of executable + dependencies" which is good enough for such complex projects as Firefox and Blender. You don't need to integrate with the OS, and you don't need to put everything in a container either. Just include all the binaries and libraries you need, and make sure everything looks in the correct path. That's it.

Containerisation is a clever technology, but I can't help feeling it's a capitulation; an admission that the compatibility problem was just too hard for us to solve.

It's undeniably useful and pragmatic, but its existence should be a source of shame, a constant reminder that we failed.

A thought that just popped up in my head: I wonder how a priest would react if someone came to the confessional to talk about Docker and the Open Container Initiative (:

I think of it exactly the opposite way. Containers show that an extremely high degree of compatibility has been achieved. Think about it, you can run new software, on an unrelated distro, even a newer distro that wasn’t planned when the host distro was created, because they all conform to the Linux ABI.

You could also "just" ship a VM disk image and cut down those variables even more...

As a user/self-administrator, I really do not appreciate a developer throwing a ton of incidental complexity over the wall. Docker is basically a scaling up of the "works on my system" cop out.

I get that there are a lot of oddball distros, but it would seem that a policy of only digging into bug reports on specific well known distros would be more appropriate than basically forgoing the entire concept of a distribution in favor of what are essentially huge static binaries.

It's especially a problem when projects go nuts with this Dockerization anti-pattern, and become actively hostile to distributions shipping plainly administerable versions of their software (looking at you Home Assistant).

There's no obligation to support every distro on the planet.

If you’ve run an open source project you will get these bug reports. It’s also not obvious if it’s a bug in your code or a dependency many times so you’re going to want to debug it.

As an example alpine has a smaller default stack size. It’s not obvious if that stack overflow is expected or not.

Sure, you might get them. But you have the option to ignore them, preferably with a friendly message back to the reporter, stating that, say, Alpine Linux is currently not supported.

Why does it matter what distro you're running on? You shouldn't be relying on anything outside of the tarball you ship, besides maybe glibc. Is there anything which can't be made to run from a self contained directory?

I'm sure Docker's great if you want to guarantee that the thing inside can't access the host system, using all kinds of kernel mechanisms, but that's generally the opposite of what you want for application software.

The main advantage of Docker for application distribution that I see is that it's lazy. You don't have to worry about keeping track of what's required, you don't have to fiddle with paths, you just hack until something works and then ship it. That's fine if you prioritize your time over your user's time.

There are alternatives listed directly below the Docker instructions. Seems like a silly reason to write-off a project.

Packages are available for just about any distro in the next heading. Source is available as well (obviously).

Still not a single binary but as you note with it being written in python and based on cdparanoia, etc how would that work?

It's based on python with relatively obscure requirements[0] that also calls out to system binaries. Looking at the Dockerfile[1] it is built with specific revs of component software to work around various issues. Take a look at the build docs and you'll see just how many existing projects (python and otherwise) it takes to deliver the end result.

IMO Docker is one of the "best" and most straightforward ways to package up all of this with the end result (as usual) putting any Linux user two commands away from ripping a disc.

[0] - https://github.com/whipper-team/whipper/blob/develop/require...

[1] - https://github.com/whipper-team/whipper/blob/develop/Dockerf...

> Still not a single binary but as you note with it being written in python and based on cdparanoia, etc how would that work?

Cosmopolitan python is a good starting point: https://ahgamut.github.io/2021/07/13/ape-python/

> IMO Docker is one of the "best" and most straightforward ways to package up all of this

No. Using containers has its place. But would you use containers on hello world?

Likewise, if you've got to use a container for cd ripping tool, you've failed somewhere.

The post you're replying to gave several reasons why something like Cosmopolitan Python is not sufficient.

This is nothing like hello world.

> This is nothing like hello world.

Full disagree. Ripping a CD in 2023 should be as complicated as hello world.

> The post you're replying to gave several reasons

Let's go through them!

> Packages are available for just about any distro

I use windows.

> It's based on python with relatively obscure requirements

So include the modules along with the cosmopolitan python

> that also calls out to system binaries

Put that logic into the cosmopolitan binary: if Linux then do this, if Windows then do that etc

> Take a look at the build docs and you'll see just how many existing projects (python and otherwise) it takes to deliver the end result.

Do the same to these extra projects.

> most straightforward way

The lazy way? Yes.

Like if you can't be bothered to implement basic features, have a billion dependencies. If as a consequence you code is unstable, put it into a container, and orchestrate.

Here's a simple C equivalent: if you have memory leaks because you know malloc() but don't know about free(), the right solution isn't to kill and respawn when you go above some memory quota, but to learn about free().

It's only for Linux and they make that absolutely clear. If you use Windows there are plenty of other options referenced in this thread and elsewhere.

This project is at least nine years old with over 1,600 commits. There are 105 open issues.

If you bothered to spend a few minutes to look at the source and open issues you'd realize how complicated and difficult it actually is to enable as many (Linux) users as possible (with cheap, out of spec, and shoddy hardware) to make close-to-perfect rips (with metadata, in multiple formats, etc) of nearly any compact disc produced over the last four decades.

Finally, as someone who has created and contributed to open source projects calling this project "lazy" is downright offensive and completely unfair. Please feel free to spend your personal time and effort to create something better. I'm sure the people who successfully use whipper everyday will be anxiously awaiting and rejoice at the release of your perfect implementation.

Then, when it (never) appears someone like you will be here trashing a design decision or compromise you made. Or, as the saying goes, I'm sure the maintainers of the project would appreciate your pull requests.

Valid criticism and debate is great (and beneficial) but your comment and attitude go way too far.

Please try to put yourself in the shoes of people who donate their time to actually produce something of value and utility (for free) only to have keyboard warriors come out of the woodwork and call them lazy.

"Why is the JavaScript ecosystem like this?" is a very similar complaint, where containers are again the dead-easy obvious answer (to almost everything, Mysql vs MariaDB difficulty remains).

Making stuff work together isnt always easy. Having a predictable easy to manage unit can be really nice, offload the particular ecosystem concerns & get folks to "just use it" places.

https://news.ycombinator.com/item?id=34250969

Yea, OP's complaint is valid, but this was the wrong project to post it on because this particular project actually does come with distro packages and source. Providing a Docker image as an option is great. Providing it as the only option, not so great.

I zone out too and thought it was just me. I think the problem is more that I don't use docker frequent enough so I have to visit the commands each time and do a refresher, which deters me.

If you set the suggested alias in your bashrc, there's nothing to remember. I use this same solution for many other things and it's fantastic.

As a mere user, the thing I like about Docker is that it centralizes the configuration settings and storage.

For most Docker instances I run I have a simple script (or compose file) which does everything, and by reading it I know exactly which configuration tweaks I did and where the data is stored. No more forgetting that one line in some non-obvious file in /etc that made everything work. Backing it all up is trivial as the volume mapping makes it clear where the important data is stored.

Of course, if the project doesn't have any dependencies and doesn't require tweaking /etc settings to work, then sure a single self-sufficient binary would suffice. However this project relies on Python, so that's probably not gonna work.

Just ship a tarball with your own Python and a venv in it. Blender ships with its own Python and it's just a tarball.

Funny, I was already pre-sad that it probably wasn't dockerized. Wonder if I can combine this with another docker project and this will rip CD's and the other will rip DVD's automatically?

> the other will rip DVD's automatically?

Do you have a specific project in mind that does DVDs?

I concur. And a standalone program written in Python. I like Python the language, but running someone else's python code is a mess. Look at the build/dependencies etc sections on the page. What it should be: "Download and install this binary for Win, this for Linux, or this for Mac. Run it to use (or install depending on complexity) the program.

Or, if building from source is desired for whatever reason, it should be "Clone the repo. Run `cargo build --release` or w/e.

Configuration software like Docker is the new Java.

No, Docker is the new apt-get.

Snap actually uses the same container technology as Docker.

(Not a fan of Snap, though)

It'd be nice if people who insist on distributing software with Docker at least made sure their images worked with rootless Docker. An ecosystem that worked with rootless Docker and that didn't leave large stray image files behind silently eating up disk space wouldn't be that bad.

Reply on news.ycombinator.com