[HN Gopher] Whipper: Accurate Audio CD Ripping
___________________________________________________________________
Whipper: Accurate Audio CD Ripping
Author : catseyechandra
Score : 191 points
Date : 2023-01-14 14:05 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| emersion wrote:
| My go-to CD ripper is https://github.com/cyanreg/cyanrip
| chuckufarley wrote:
| 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..
| accrual wrote:
| 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.
| SloopJon wrote:
| 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?
| xprueg wrote:
| 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/
| SloopJon wrote:
| 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.
| extra88 wrote:
| 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.
| keybits wrote:
| 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!
| extra88 wrote:
| 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...
| rsync wrote:
| "... 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
| azornathogron wrote:
| 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.
| Taywee wrote:
| FLAC is lossless. Any audio CD ripped and encoded to FLAC
| will be the exact same accuracy as WAV.
| ericbarrett wrote:
| 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.
| bunabhucan wrote:
| 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
| pwg wrote:
| > 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).
| nofreelunch wrote:
| 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.
| bombcar wrote:
| Hard drive space is cheap. Do both.
| jcollins1991 wrote:
| 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
| 2OEH8eoCRo0 wrote:
| 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.
| thriftwy wrote:
| Linux has cdparanoia for decades now, which doea all that stuff
| and I'm not sure what's new about Whipper.
| medler wrote:
| 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
| thriftwy wrote:
| I remember tools such as Asunder and grip adding passable
| GUIs around cdparanoia.
| Etheryte wrote:
| Always makes me sad remembering what was lost when What.CD went
| offline.
| ThePowerOfFuet wrote:
| Oink.
| JTon wrote:
| And Oink before it. But the torch has been passed to the next
| community, not all has been lost
| teawrecks wrote:
| 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.
| giardia wrote:
| The pink palace! I miss it.
| auxym wrote:
| And oink, waffles, Pedro's. It was the golden age of piracy.
| dsr_ wrote:
| 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.
| jancsika wrote:
| 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.
| 112233 wrote:
| 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.
| joe-user wrote:
| > 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.
| saba2008 wrote:
| 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
| kevin_thibedeau wrote:
| 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.
| ataylor32 wrote:
| Do you do anything to handle "hidden tracks" (i.e. the last
| track has some audio, then some silence, and then some more
| audio)?
| jszymborski wrote:
| Just in case anyone was wondering, EAC works without a hitch
| with WINE on Linux.
| Gigachad wrote:
| 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.
| TacticalCoder wrote:
| > 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._
| xen2xen1 wrote:
| 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.
| [deleted]
| gjsman-1000 wrote:
| 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).
| kreetx wrote:
| 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.
| mynameisash wrote:
| 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.
| aDfbrtVt wrote:
| Picard has worked really well for me.
|
| https://picard.musicbrainz.org/
| bismark wrote:
| You could check out https://beets.io/
| meindnoch wrote:
| Good for personal use, but in the scene you must use a recent
| enough version of EAC or XLD.
| [deleted]
| medwards666 wrote:
| My go-to audio CD ripper is this: https://www.exactaudiocopy.de/
| pelorat wrote:
| 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.
| andy_ppp wrote:
| So why would ripping CDs result in less than perfect copies - I
| thought digital information would almost always be read
| correctly?
| PragmaticPulp wrote:
| 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.
| LeoPanthera wrote:
| 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.
| LarryMullins wrote:
| 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.
| ghusbands wrote:
| 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.
| CGamesPlay wrote:
| I read the linked rationale and still don't understand why this
| is even a problem.
| I_AM_A_SMURF wrote:
| 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.
| kevin_thibedeau wrote:
| 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.
| rlv-dan wrote:
| Transferring from disc to system via a laser is analogue and
| error prone. What if there is a scratch? What if the cd
| wobbles?
| asveikau wrote:
| That's what the CRC is for.
|
| Granted, it's not perfect...
| andy_ppp wrote:
| But then the CD should skip right or reread the bits -
| maybe it doesn't maybe it guesses to keep the music
| playing...
| asveikau wrote:
| 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.
| indigodaddy wrote:
| 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.
| BennyInc wrote:
| 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.
| CharlesW wrote:
| 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/
| catseyechandra wrote:
| For audio geek who wants a high quality audio extraction from
| their CD collection
| lern_too_spel wrote:
| Why would I use this over abcde, another cdparanoia frontend
| that is packaged for every major distro?
| SinePost wrote:
| 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.
| thebrid wrote:
| 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.
| rsync wrote:
| 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 ...
| haunter wrote:
| Thank you Chat GPT
| wyager wrote:
| 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.
| amacneil wrote:
| Fyi this is just the OP adding a description
| victorvosk wrote:
| 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.
| croes wrote:
| In the 00s you just used Exact Audio Copy
| orangepurple wrote:
| Still used in Russia constantly. It's the gold standard.
| criddell wrote:
| Audiophile nerds have moved on to digital formats that are much
| higher res than CD or have gone 100% analog.
| dmitryminkovsky wrote:
| 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.
| dstaley wrote:
| 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.
| aforwardslash wrote:
| 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
| bagels wrote:
| Aac on an SSD or on the internet?
| flatiron wrote:
| 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.
| IndySun wrote:
| 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?
| haunter wrote:
| >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
| flatiron wrote:
| My audio now is usually played via AirPods. So any lossless
| rip is lost on me since it's compressed anyway.
| layer8 wrote:
| But you could avoid it being compressed twice, which can
| introduce additional artifacts.
| rokweom wrote:
| >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?
| IndySun wrote:
| >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.
| rokweom wrote:
| >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?
| IndySun wrote:
| 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.
| mckirk wrote:
| > 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
| IndySun wrote:
| 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.
| user3939382 wrote:
| I haven't needed to solve this problem since somewhere around
| 2003 but my tool used to be CDex https://cdex.mu/screenshots
| sickcodebruh wrote:
| 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.
| coopl wrote:
| Wait what? How does this work? Which CDs had music stored
| before the start of the first track?
| exitb wrote:
| 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.
| ..
| didntreadarticl wrote:
| 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...
| lozf wrote:
| "Blumenkraft" by OTT, but only on the CD, not the download
| from https://ottsonic.bandcamp.com
| nofreelunch wrote:
| [dead]
| kevin_thibedeau wrote:
| 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.
| sirjaz wrote:
| 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.
| yuvadam wrote:
| The project has external dependencies including dynamic libs
| that you cannot just compile to run on Windows and Mac.
| thrownawaysz wrote:
| >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/develop/whipper...
| the__alchemist wrote:
| 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.
| kkielhofner wrote:
| 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...
| csdvrx wrote:
| > 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.
| anamexis wrote:
| The post you're replying to gave several reasons why
| something like Cosmopolitan Python is not sufficient.
|
| This is nothing like hello world.
| csdvrx wrote:
| > 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().
| kkielhofner wrote:
| 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.
| ryandrake wrote:
| 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.
| rektide wrote:
| "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
| gompertz wrote:
| 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.
| freedomben wrote:
| 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.
| magicalhippo wrote:
| 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.
| dTal wrote:
| 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.
| xen2xen1 wrote:
| 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?
| mynameisash wrote:
| > the other will rip DVD's automatically?
|
| Do you have a specific project in mind that does DVDs?
| nixpulvis wrote:
| Configuration software like Docker is the new Java.
| amelius wrote:
| No, Docker is the new apt-get.
|
| Snap actually uses the same container technology as Docker.
|
| (Not a fan of Snap, though)
| quotemstr wrote:
| 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.
| sschueller wrote:
| I agree with you, however if I had to pick between snap and
| docker I would go with docker evertime.
| [deleted]
| jdsully wrote:
| 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.
| dTal wrote:
| 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.
| robinsonb5 wrote:
| 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.
| cpach wrote:
| 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 (:
| wwarner wrote:
| 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.
| mindslight wrote:
| 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).
| je42 wrote:
| How about flatpak? To fulfil this function?
| hezag wrote:
| And snap, Appimage...
| dTal wrote:
| 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.
| kleiba wrote:
| There's no obligation to support every distro on the planet.
| [deleted]
| jdsully wrote:
| 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.
| orangepurple wrote:
| It's like people forget statically compiled binaries exist
| [deleted]
| skybrian wrote:
| It's a good solution, but there are popular programming
| languages where that doesn't work.
| tyrust wrote:
| There are alternatives listed directly below the Docker
| instructions. Seems like a silly reason to write-off a project.
| sbaiddn wrote:
| 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?
| haunter wrote:
| 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/
| sbaiddn wrote:
| 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
| ectopod wrote:
| 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.
| joshenders wrote:
| 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 ;)
| einherjae wrote:
| 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.
| sbaiddn wrote:
| So the error are used to trip traditional tools like ddrescue
| like in the days of old?
| einherjae wrote:
| 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/we
| b/20160528213242/https://thomas.ap...
| wooptoo wrote:
| 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`
| acidburnNSA wrote:
| 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/
| TacticalCoder wrote:
| 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.
| cogman10 wrote:
| 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.
| acidburnNSA wrote:
| 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!
| hulitu wrote:
| It depends on what audio setup you do the listening. On
| laptop speakeakers it will be no difference.
| acidburnNSA wrote:
| I did an abx test on reasonable caliber headphones. Try
| it! It surprised me.
| asveikau wrote:
| 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.
| cogman10 wrote:
| > 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.
| asveikau wrote:
| 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..)
| hulitu wrote:
| The dinamics of mp3 is much lower.
| cogman10 wrote:
| 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).
| acidburnNSA wrote:
| 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.
| rsync wrote:
| "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.
| ripdog wrote:
| 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.
| sandreas wrote:
| 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/
| MengerSponge wrote:
| Ooo, I can finally get a bit-perfect copy of "Teenage Wasteland"?
| Rad.
| seabrookmx wrote:
| Nice
| visarga wrote:
| What is an audio CD and where do you stick it?
___________________________________________________________________
(page generated 2023-01-14 23:00 UTC)