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

111–120 of 217 posts

Re: Whipper: Accurate Audio CD Ripping

#111

Post by acidburnNSA »

cogman10 wrote: post #106
acidburnNSA wrote: post #97

Earlier quoted context omitted.

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

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.

Re: Whipper: Accurate Audio CD Ripping

#112

Post by kevin_thibedeau »

I_AM_A_SMURF wrote: post #99
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.

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.

Re: Whipper: Accurate Audio CD Ripping

#113

Post by BennyInc »

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.

Re: Whipper: Accurate Audio CD Ripping

#114

Post by cogman10 »

asveikau wrote: post #103
acidburnNSA wrote: post #97

Earlier quoted context omitted.

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…

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

Re: Whipper: Accurate Audio CD Ripping

#115

Post by jcollins1991 »

bombcar wrote: post #83
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…

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

Re: Whipper: Accurate Audio CD Ripping

#116

Post by rektide »

kkielhofner wrote: post #44
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…

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…

"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

Re: Whipper: Accurate Audio CD Ripping

#117

Post by [deleted] »

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…

[deleted]

Re: Whipper: Accurate Audio CD Ripping

#118

Post by kevin_thibedeau »

coopl wrote: post #18
sickcodebruh wrote: post #8

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?

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.

Re: Whipper: Accurate Audio CD Ripping

#119

Post by asveikau »

cogman10 wrote: post #114
asveikau wrote: post #103

Earlier quoted context omitted.

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…

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

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

Re: Whipper: Accurate Audio CD Ripping

#120

Post by csdvrx »

anamexis wrote: post #88
csdvrx wrote: post #85

Earlier quoted context omitted.

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

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

Post reply on HN