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

101–110 of 217 posts

Re: Whipper: Accurate Audio CD Ripping

#101

Post by SloopJon »

xprueg wrote: post #91
SloopJon wrote: post #41

Earlier quoted context omitted.

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/

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.

Re: Whipper: Accurate Audio CD Ripping

#102

Post by asveikau »

rlv-dan wrote: post #82
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?

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

Re: Whipper: Accurate Audio CD Ripping

#103

Post by asveikau »

acidburnNSA wrote: post #97
cogman10 wrote: post #95

Earlier quoted context omitted.

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/manpage…

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.

Re: Whipper: Accurate Audio CD Ripping

#104

Post by dTal »

hezag wrote: post #80
je42 wrote: post #60

Earlier quoted context omitted.

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.

Re: Whipper: Accurate Audio CD Ripping

#105

Post by wwarner »

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.

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.

Re: Whipper: Accurate Audio CD Ripping

#106

Post by cogman10 »

acidburnNSA wrote: post #97
cogman10 wrote: post #95

Earlier quoted context omitted.

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/manpage…

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

Re: Whipper: Accurate Audio CD Ripping

#107

Post by dTal »

magicalhippo wrote: post #46
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…

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

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.

Re: Whipper: Accurate Audio CD Ripping

#108

Post by dTal »

jdsully wrote: post #39
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…

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.

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.

Re: Whipper: Accurate Audio CD Ripping

#109

Post by kevin_thibedeau »

saba2008 wrote: post #38
jancsika wrote: post #19

Earlier quoted context omitted.

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…

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.

Re: Whipper: Accurate Audio CD Ripping

#110

Post by LeoPanthera »

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?

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.

Post reply on HN