Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Whipper: Accurate Audio CD Ripping

github.com

Post reply on HN
Print view View original

91–100 of 217 posts

Re: Whipper: Accurate Audio CD Ripping

#91

Post by xprueg »

SloopJon wrote: post #41
accrual wrote: post #3

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 pr…

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 Foo…

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/

Re: Whipper: Accurate Audio CD Ripping

#92

Post by joe-user »

jancsika wrote: post #19
accrual wrote: post #3

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 pr…

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…

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

Re: Whipper: Accurate Audio CD Ripping

#94

Post by ectopod »

sbaiddn wrote: post #64
haunter wrote: post #15

Earlier quoted context omitted.

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/

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.

Re: Whipper: Accurate Audio CD Ripping

#95

Post by cogman10 »

acidburnNSA wrote: post #84

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 --conf…

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.

Re: Whipper: Accurate Audio CD Ripping

#96

Post by cpach »

robinsonb5 wrote: post #72
jdsully wrote: post #39

Earlier quoted context omitted.

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.

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

Re: Whipper: Accurate Audio CD Ripping

#97

Post by acidburnNSA »

cogman10 wrote: post #95
acidburnNSA wrote: post #84

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 --conf…

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…

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!

Re: Whipper: Accurate Audio CD Ripping

#98

Post by quotemstr »

thrownawaysz wrote: post #29

>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... 0, https://github.com/whipper-team/whipper/blob…

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.

Re: Whipper: Accurate Audio CD Ripping

#99

Post by I_AM_A_SMURF »

andy_ppp wrote: post #75

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

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.
Post reply on HN