Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Rip losslessly to flac with abcde UNIX
All the ways I could find to rip to flac on OS X involved way too many steps for my taste. So here's my solution...

The first step is to install DarwinPorts. Once that's done, switch to the Terminal and type sudo port install abcde. Go and drink a beer while you watch abcde and all its dependencies invade your space.

Once that's done, create ~/.abcde.conf with the following contents. (If /dev/disk1 isn't your CD-ROM, then adjust it.):
CDROM=/dev/disk1
OUTPUTTYPE=flac
INTERACTIVE=n
PADTRACKS=y
OUTPUTDIR=~/Music/abcde
OUTPUTFORMAT='${ARTISTFILE}/${ALBUMFILE}/${TRACKNUM} - ${TRACKFILE}'
VAOUTPUTFORMAT='Various/${ALBUMFILE}/${TRACKNUM} - ${TRACKFILE}'
mungefilename ()
{
  echo "$@" | sed s,:, -,g | tr /* _+ | tr -d '"?[:cntrl:]
}
The disk arbitration daemon automatically mounts a CD when you insert it, but abcde works on the raw block device and can't access it if it's mounted. So we need a simple shell script. Call it rip, because it does:
#!/bin/bash
#

diskutil unmount /dev/disk1
abcde
diskutil eject /dev/disk1
Insert a CD and type rip. Drink another beer. When your new folder of glorious lossless flacs lands in ~/Music/abcde, the CD will pop out.

This approach gambles on the first result from freedb being what you want and not needing corrections. That is a thin proposition much of the time, but you can always interrupt and run abcde interactively if you see errors in the data.

[robg adds: I haven't tested this one...]
    •    
  • Currently 3.25 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (4 votes cast)
 
[24,951 views]  

Rip losslessly to flac with abcde | 39 comments | Create New Account
Click here to return to the 'Rip losslessly to flac with abcde' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Rip losslessly to flac with abcde
Authored by: Gerk on Oct 21, '05 07:47:01AM

lossless is subjective term. Sadly, flac is NOT a lossless format in the true sense of the term although it claims to be. We tested quite a few different "lossless" formats and a couple of the big players (namely flac and apple's lossless) aren't really lossless after all. We put a bunch of these codes through some grueling tests to see just how lossless they were and flac showed loss on compression/decompression. In fact it showed significant audio artifacts. Apple's lossless was worse however!

Just wanted to chime in here with that information.

It's a good format, but for people that are trying to choose a good format for long term archival that is truly lossless I would recommend using either wav/aiff (which are truly lossless as there is no conversion!) or monkey audio's .ape.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: hamarkus on Oct 21, '05 08:01:11AM

Wouldn't zip or sitx be truely lossless archival audio formats. Sure they cannot be decoded as they are played, but decoding would only take a few seconds anyway.

Just compressed an aiff file (3.6 MB) with Apple's zip: 2.1 MB, using sitx they size comes down to 1.2 MB.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: shoelzer on Oct 21, '05 08:13:25AM

Gerk, can you provide more info about the "grueling tests" and what kinds of "audio artifacts" you found. It seems that a lossless codec test wouldn't need to look for audio artifacts; just do a binary compare of the input and output wav/aiff files.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: Gerk on Oct 21, '05 09:13:27AM

We used a couple of different methods to test the codecs with some specially crafted audio samples.

We did both binary bit comparison (cmp command) as well as a testing the original WAV/AIFF against a compressed/decomrpessed one by putting the original sound in phase (0 degrees) and the comparing sound out of phase (180 degrees) In a perfect world they would cancel each other out perfectly ... which they didn't -- there were artifacts. The same files that had artifacts failed the binary comparison tests.

For some simpler audio files it was lossless, for the specially crafted ones it was not. The specially crafted files contained things like white noise, generated audio tones (sawtooth, square wav, etc), spectrum sweeps and other complex audio samples.

We're still gathering some of the last findings and will be posting all of our results. The tests were done by several audio professionals running different operating systems (OSX/Windows/Linux/BSD) to rule out software type/versions causing inaccurate results. Once it's posted I'll try and remember to post the link in this thread -- it may take a while still.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: fracai on Oct 21, '05 09:38:58AM

Then I think your tests WERE flawed.

Without seeing the full results it's hard to comment, but it sounds like the music tests were fine. I don't know many people who sit around listening to white noise and sine waves as a means of entertainment.

It seems to me that flac is lossless for the sound files it was intended to process.

I'll be interested to see your full results and testing measures of course. Where will these be posted when done?

---
i am jack's amusing sig file



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: shoelzer on Oct 21, '05 09:58:12AM

It doesn't matter if the source file is music or noise. Lossless should be lossless. If there are any errors with any type of input, the audio codec isn't truly lossless.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: kd4ttc on Oct 21, '05 10:18:27AM

No, that is not true. Giving input which does not meet the specification is an invalid test. These codecs expect audio. If you throw at it non-audio you have an invalid test. If you have a system that will do arithmetic on dollars and cents and you give a test suite including data with 10ths of cents you have an unreasonable test.

Even the 180 out of phase test is a mistake if you do not adjust for different latencies. And if the latencies vary over time it should also not matter.

---
Stephen Holland, M.D.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: shoelzer on Oct 21, '05 10:51:55AM

It is true. These codecs expect audio in the sense that the input must be a valid audio format supported by the codec but it does not matter what type of signal was encoded in that audio format. It could be music, a square wave, noise, or a list of winning lottery numbers -- it makes no difference to the encoder.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: BadgerUMD on Oct 21, '05 11:05:30AM

Not really true -- a true square wave has infinite frequencies (or at least higher than the sampling rate and your range of hearing), which any encoder (even "lossless" WAV) will alias to lower frequencies that you "can" hear. So if one encoder suppresses these alias frequencies better it doesn't make it more "lossless" -- you've simply passed data to the encoder that the writes didn't expect -- non-audio data.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: shoelzer on Oct 21, '05 11:15:27AM

Yes, it really is true. I'm talking about the codec being lossless. If the audio samples coming out match the audio samples that went in, it's lossless. You're talking about the sampling process being lossy, which of course is true, but it's a totally different issue.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: kd4ttc on Oct 21, '05 03:11:31PM

The thing the codec is trying to be smart about is to work with audio that really will come along. If the inventors of a codec realize through analysis of real audio that certain frequencies never come up in real life, then develop a codec that takes advantage of that truth of nature they may have an insight that allows a significant advance in technology. So if it is lossless with real audio but loses certain frequency components in fantasy signals I would still call it lossless.

Just because an arbitrary waveform has a certain frequency in the range of 50 Hz to 20 kHz does not make it a valid audio input. True square waves of pressure in air cannot be generated by any known phyisical method. No moving body can instantaneously move. Even electronic circuits that generate square waves are limited by rise times and may exhibit slight ringing.

As far as square waves and audio circuits, a crude test of audio gear is to run a square wave through and see what comes out. However, the purpose of this is not to look for whether the process drops a bit. One scopes the output looking for rolloff, ringing, and high and low frequency losses.

For audio testing that would be relevant consider something like the test disk at http://www.interstudio.co.uk/sndchk.htm That will privide not only audio that is well selected for testing sound reproduction equipment, but would be a suite that others could use in independent verification of the system.

Running a square waveform into a codec may be an easy test, but the ease with which it is done misses the point of why the testing is done in the first place.

---
Stephen Holland, M.D.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: DylanMuir on Oct 25, '05 01:49:03AM
"Lossless compression" means no information is thrown away.

MP3 and FLAC are analogous to JPEG and GIF, or ZIP. JPEG and MP3 throw away information that is considered unimportant, or below our threshold of detection. FLAC, GIF and ZIP should take some binary stream and compress it in a way that that stream can be recovered PERFECTLY.

Arguing about square waves misses the point -- FLAC can encode any valid PCM stream and reproduce it bit for bit on decompression. The sampling process that makes a true square wave impossible is not the issue here.

D.

[ Reply to This | # ]

Rip losslessly to flac with abcde
Authored by: n8gray on Oct 21, '05 12:04:13PM
No, that is not true. Giving input which does not meet the specification is an invalid test. These codecs expect audio. If you throw at it non-audio you have an invalid test. If you have a system that will do arithmetic on dollars and cents and you give a test suite including data with 10ths of cents you have an unreasonable test.

Sorry, you're flat-out wrong. FLAC is designed to compress any PCM stream so that it can be decompressed without loss. It is designed to be very efficient for music, but it should never lose information for any PCM stream including white noise, square waves, etc. If somebody was complaining that FLAC didn't achieve a high compression ratio on white noise, then your criticism would be justified. Indeed, it's likely that FLAC "compression" would make a white noise file larger.

Even the 180 out of phase test is a mistake if you do not adjust for different latencies. And if the latencies vary over time it should also not matter.

The out-of-phase test would be trivial to get right, but why bother? The only thing that matters is the binary difference test. Actually, I guess it might be a useful way to find out if the errors were spread out over the entire file or just in one chunk somewhere.

[ Reply to This | # ]

Problems with your test methods ...
Authored by: BadgerUMD on Oct 21, '05 10:02:41AM

In reading your test methods, I have to say it seems as if each one is significantly flawed in some way (although you may have omitted details for brevity's sake). Warning -- this post is overly long! I apologize, but I thought that Gerk might want some constructive criticism.

>> "We did both binary bit comparison (cmp command) ..."

I can't see this test being meaningful for any comparison of the files involved -- since the files are of different formats, insignificant format differences would result in significant changes in the files. If you are comparing the output to the sound card, however, that *should* work (more about why it may not later).

>> "... the original WAV/AIFF against a compressed/decompressed one by putting the original sound in phase (0 degrees) and the comparing sound out of phase (180 degrees) ..."

I can see a LOT of ways this test could fail, and it wouldn't make Flac (or others) "un-lossless". Mostly they have to do with sampling and the way you took the sound 180 degrees out of phase (more on sampling later). Mostly though is because we don't live in a perfect world, from a signal processing point of view, and except for very simple waveforms, I don't think you could cancel out sounds this way anyway.

>> "For some simpler audio files it was lossless, for the specially crafted ones it was not. The specially crafted files contained things like white noise, generated audio tones (sawtooth, square wav, etc), spectrum sweeps and other complex audio samples."

I had the most trouble with this. There is NO digital format which can faithfully reproduce the sounds you hear. This is because all of the digital formats work by sampling the sound signal (usually at about 44000 Hz) and basically recording the signal's amplitude every 1/44000 seconds. Just doing this loses information -- there is absolutely no way (especially with complex sounds) you could *NOT* lose information doing this. This means that any "lossless" format needs to be lossy to be represented digitally. (although usually this can be decreased to where you can't hear it).

Then, the even bigger problem is that the true white noise, sawtooth, and square wave samples all have infinite frequency components (or at least WAY above 22000Hz, the highest frequency you can get with 44000 sampling). That means, when the audio sample is sampled, those higher frequency artifacts (which you can't hear anyway) are aliased to lower frequency components that you CAN hear. These artifacts may be absent from WAV if the WAV encoder you used pre-filters the incoming filter before sampling (a common practice) and present in other formats because they assume that no one would be encoding a sound that no one could hear anyway (which is what a CD's input to these encoders would be). So a more fair comparison would be to input only those sounds into the encoders which a human can hear -- white noise et. al. don't represent those sounds.

I hope this helps you revise your tests, or at least describe them in such a way that your article is well received.



[ Reply to This | # ]
Problems with your test methods ...
Authored by: c15zyx on Oct 21, '05 10:44:24AM

Some good points here. Having sounds compared by using phasing is kinda of pointless. In general when generating any kind of extra processing it's hard to keep track of possible added variabilities along the way.

All you need to do is take pcm data straight from the input wav and encode. Then decode to wav and extract and compare the pcm data. Since pcm data contains only raw audio samples, you can just bit-compare the results. Nice and simple. A difference between two values in this case can mean one of 3 things- the encoder is buggy, the decoder is buggy, or the underlying mathematical algorithms are spotty.



[ Reply to This | # ]
Be more careful with presentation
Authored by: n8gray on Oct 21, '05 12:22:31PM
It appears that your methodology is sound, but you should be more careful about how you present these results. It's quite likely you're revealing bugs with one implementation of the FLAC algorithm, not fundamental problems in the design of FLAC. Unless you show your test files to the FLAC team and they say "yes, this is a design flaw and no, we aren't going to fix it" then claiming that "FLAC is not a lossless format" is inaccurate, misleading, and defamatory, and you're opening yourself up to a boatload of justified flameage.

[ Reply to This | # ]
Be more careful with presentation
Authored by: Githon on Oct 23, '05 09:56:26AM

Because saying "This codec loses something, therefore is not lossless" is entirely inflammatory and unfair.

Just like saying "The phone company isn't giving you a free cell phone" when part of your bill says "Free phone fee: $270".



[ Reply to This | # ]
Be more careful with presentation
Authored by: n8gray on Oct 25, '05 12:08:51AM
Because saying "This codec loses something, therefore is not lossless" is entirely inflammatory and unfair.

No, because saying "FLAC is not a lossless codec" is different from saying "one particular implementation of FLAC has a bug that can cause loss." Claiming that the FLAC algorithm is not lossless is an accusation that its authors are intentionally misleading people by saying otherwise. I would say that without some serious evidence, yes, such a claim is inflammatory and unfair. It's FUD, plain and simple, because it leads people to the incorrect conclusion.

Just like saying "The phone company isn't giving you a free cell phone" when part of your bill says "Free phone fee: $270".

No, not really. It's more like claiming "The phone company is lying and isn't giving anybody a free cell phone" when they actually just accidentally billed you for it but were completely willing to correct their mistake. The difference is what you're saying about the intent of the other party.

[ Reply to This | # ]

Be more careful with presentation
Authored by: Githon on Oct 30, '05 11:54:34AM

And you're certainly not assigning malicious intent to his statements, no sir.



[ Reply to This | # ]
Be more careful with presentation
Authored by: n8gray on Nov 01, '05 04:42:07PM
And you're certainly not assigning malicious intent to his statements, no sir.

Actually, if you read my post you might notice I said nothing about his intent, only the nature of his statements. I can understand the mistake -- it's a subtle distinction.

[ Reply to This | # ]

Rip losslessly to flac with abcde
Authored by: genericuser on Oct 21, '05 08:43:55AM

Tests over at Hydrogen Audio tend to disagree with you. Could you give specifics as the few tests I've seen of WAV versus WAV>ALAC>WAV were bit identical.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: c15zyx on Oct 21, '05 09:11:45AM

Then your tests were possibly flawed or you used miscompiled binaries (correct algorithms and implementation are good, but you still must trust the compiler to generate correct code).

Comparing raw pcm data before and after encoding to FLAC shows bit-identical results in all samples I've tested. It's possible (but unlikely) there might be a bug, but if that's the case you should report it to the FLAC developers.

Apple Lossless had a bug in earlier versions available that caused truncation for some samples, but I think the problem might have been fixed, either way I'd prefer FLAC or wavpack.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: Gerk on Oct 21, '05 09:18:16AM

See my reply above for more information. Of note the tests that failed were not with music, but with sine wav sweeps, white noise, and generated audio tones. We also worked with various operating systems using both pre-compiled binaries and in some cases we compiled from the latest sources.

If we find reproducible problems we'll be sure to submit bugs to the developers along with the samples that triggered the problems, that was one of the points of the exercise! :)



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: TekkNick on Oct 21, '05 10:49:30AM

FLAC is indeed lossless. I just finished re-RIPing my entire collection so that as new/better formats come out I can re-encode without that hassle. I used FLAC to minimize the storage requirement. Paranoia got the best of me. I was not going to go through all that hassle (some 500 discs) only to find out that the decoded FLAC files weren't bit-for-bit copies of the originals. I wrote a script that encoded, decoded and diffed every track before permanently deleting the WAV. I can't speak for previous versions, but flac 1.1.2 is as reliable as zip with a lot higher compression ratio.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: jctull on Oct 21, '05 08:36:06AM

You can also use the fink package management system. It is available in the unstable branch.



[ Reply to This | # ]
Suggested workflow single-file CD archival?
Authored by: acet on Oct 21, '05 11:29:51AM

This hint is so closely related and also judging by some of the comments I've seen so far, I thought I'd ask something I've been grappling with for a while.

Does anybody have any suggestions on a simple workflow for lossless CD archival? I've looked at a number of potential solutions and it seems that FLAC is a good candidate with its .cue sheet support. However I've yet to find anything so far that's stiched everything together in an easy-to-use and efficient workflow suitable for permanently archiving my hundreds of CD's. I've hoped that abcde would have this support but from so far as I can tell, it's not quite there yet.

To be clear, the problem I'm facing is that my music listening habits these days are 100% digital. When I buy a CD, it gets immediately ripped to .mp3 and then tossed in a box in the attic to collect dust for years. Despite the fact that I never play my CD's, they still seem to somehow take damage and I know that in 10 years some of them will simply be unreadable. Since it's only the data and not the plastic that it's imprinted upon that I care about, I'd like to once and for all find a way to make a perfect backup of the CD that I can protect with established data-archival habits and do away with the bulk and the bit rot of the physical media.

FLAC looks great for this... it sounds like you can theoretically make a single file compressed representation of an audio CD and then later use that to re-create a perfect copy of the original, with all of the index markers and TOC contents. But everything I've seen so far suggests I'd have to spend weeks scripting together some sort of custom workflow to encode and label my entire collection.

There has to be a better way... has anybody found it yet?



[ Reply to This | # ]
Suggested workflow single-file CD archival?
Authored by: hamarkus on Oct 21, '05 01:27:31PM

To repeat myself, what is wrong - for archival purposes - with a zip file?



[ Reply to This | # ]
Suggested workflow single-file CD archival?
Authored by: grahams on Oct 21, '05 01:55:09PM

There is nothing wrong with it, the only real "problem" is that you get a lousy compression ratio. FLAC (and Apple Lossless) give you about a 50% reduction in file size while being lossless (you can regenerate a bit for bit replica of the source WAVE file from the FLAC file).

ZIP, on the other hand, while it is good at compressing other types of data (text, etc), it doesn't do so well at Audio files. Do a side-by-side comparison of ZIP and FLAC, and you'll see that you only get a few percent reduction in file size with ZIP while, again, you usually get about a 50% reduction with FLAC. FLAC is able to accomplish this because it is a compression algorithm tuned for working with audio data. Just as ZIP (a general purpose compression algo) is bad at audio (and other file types) compression, FLAC wouldn't do a good job of compressing a text file (if you could manage to shoehorn the tools to try in the first place).

ZIP's compression ratio (for audio files) is so minimal it doesn't even really make sense to ZIP the files at all, your space gains are so low you might as well leave them uncompressed and playable on demand.



[ Reply to This | # ]
Suggested workflow single-file CD archival?
Authored by: acet on Oct 21, '05 03:36:10PM

To echo the previous responders comments, a ZIP file doesn't compress audio data nearly as well as FLAC. ZIP is a general purpose compression algorithm, while FLAC and others are specifically tooled to take advantage of the typical patterns in audio, resulting in higher compression ratios at the expense of being limited to a specific type of data.

Also, this still doesn't address the issue of capturing the meta info contained in a CD, like the table of contents and precise track layout.



[ Reply to This | # ]
Suggested workflow single-file CD archival?
Authored by: JohnBigBoots on Oct 21, '05 02:19:43PM
I use cdparanoia and cdrdao (from DarwinPorts or Fink) to duplicate my audio CD's. It doesn't offer any compression, but it does make a nearly identical copy.

script cdrdao_read

#!/bin/bash
echo Insert your disk now...
while (( 1 )); do drutil status | egrep -q 'Type: No Media Inserted' && sleep 1 || break; done
device=$(ioreg -c IOCDMedia | egrep 'disk[[:digit:]]+' | cut -d" -f4)
disktool -u "${device}" && \
cdparanoia -fz 1- "$@.aiff" && \
cdrdao read-toc --device IODVDServices/1 --driver generic-mmc --with-cddb --cddb-servers freedb.freedb.org --cddb-directory "${HOME}/.cddb" --datafile "$@.aiff" "$@.toc"
drutil tray eject


Script cdrdao_write

#!/bin/bash
echo Insert your disk now...
while (( 1 )); do drutil status | egrep -q 'Type: No Media Inserted' && sleep 1 || break; done
device=$(ioreg -c IOCDMedia | egrep 'disk[[:digit:]]+' | cut -d" -f4)
disktool -u "${device}" && \
cdrdao write --device IODVDServices/1 --eject "$@"
drutil tray eject

Note: You may need to create ${HOME}/.cddb if it doesn't exist. Only tested on Tiger OS X 10.4.x

[ Reply to This | # ]
Suggested workflow single-file CD archival?
Authored by: JohnBigBoots on Oct 21, '05 02:22:58PM

Crap, the "&&" should be "&& <backslash symbol here>". The backslash got stripped out of the html. Sorry



[ Reply to This | # ]
Suggested workflow single-file CD archival?
Authored by: JohnBigBoots on Oct 21, '05 03:02:02PM

Crappy, crap. I should have given basic instructions for use. At a termnal prompt type "bash ./cdradao_read MyCDName" (without the quotes) to read a CD.

Then type "./cdrdao_write MyCDName.toc" (w/o quotes) to write to a blank CD-R.

Important! In "System Preferences->CD's & DVD's", set "When you insert a Music CD" and "When you insert a blank CD" to "Ignore" in order to prevent other applications, like iTunes, from taking control of the optical drive.

Sorry for the bad instructions. Enjoy, eh?



[ Reply to This | # ]
Suggested workflow single-file CD archival?
Authored by: doneitner on Oct 21, '05 07:16:19PM

Unfortunately for my needs (desires) I have not found a native MacOS X option for archiving my audio CDs to FLAC. All the tools are available, but they're all separate. What I've used is a program on Windows called CDEX. It does the CDDB lookup (and allows me to edit the song titles, etc. if necessary), it does the ripping and (with flac.exe installed as an external encoder, which CDEX supports directly) it does the encoding. What I'm left with is a folder of /artist_name/album_name/ with each track listed in order, in FLAC format and having the ID3 tags (or whatever tag format FLAC uses) filled in with the relevant information.

I would LOVE to have such an all-in-one solution on the Mac. The only thing that comes close is iTunes but iTunes doesn't support FLAC in any way shape or form that I can find. I specifically chose not to use Apple Lossless because, honestly, I can't say that in 10 years I'll be using a system that Apple supports and FLAC, being open source, if necessary I could compile it for whatever system I use and be able to convert my audio into some other useful format then.



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: rspress on Oct 22, '05 12:16:35PM

I just use MacFLAC or xACT, those seem pretty simple to me and no code needed!



[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: extempore on Oct 24, '05 01:25:07PM

I'm sorry to see the hint was hijacked by a long wrong-headed discusison about whether flac is lossless. The claim that flac is not lossless is pure FUD. There is something wrong with the claimant's tests. Many thousands of people are using the codec. If you're paranoid it has an option to decode the compressed audio at the same time it is encoding it to verify that the original and decoded versions are bitwise identical. If it ever failed it would be huge news.

It's about as likely that flac loses information as that gzip does. Please pay no mind to this outlandish claim.



[ Reply to This | # ]
Rip to FLAC with Toast 7
Authored by: Arturia on Oct 24, '05 06:30:22PM
I don't want to do a publicity stunt for anyone...
but, just so you know, Roxio Toast 7 is also able to encode to and from FLAC

[ Reply to This | # ]
DarwinPorts install guide
Authored by: SnowLprd on Feb 06, '06 07:50:09AM
Just posted a handy guide to installing DarwinPorts:

Installing DarwinPorts on Mac OS X

[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: extempore on May 01, '07 07:18:11AM
Hint author here. This hint no longer works as presented thanks to changes in the underlying programs, but fortunately there is a much better freeware solution now. Use Max to rip to flac (and do many other things.)

[ Reply to This | # ]
Rip losslessly to flac with abcde
Authored by: mezzaluna on Jun 07, '08 06:51:28AM

I'm looking for a more efficient way to rip and encode CDs. abcde looks like exactly the right thing. Unfortunately, it fails on my G4 powerbook running 10.5.3. Anyone used this successfully under 10.5?

I've tried abcdb v2.2.6, which is the version installed by fink, and v2.3.3, which is the latest version I found on the web site, http://www.hispalinux.es/~data/abcde.php

Here's the failure. I think I'm reading the disk, getting to cddb, etc. Oddly, "line 2731" is a call to cddb-tool, which seems to work properly to get the disk info.

bash-3.2$ abcde
disk1 device will be unmounted ...
***Notifications Complete for type 1
***Responding yes to unmount - disk1
***Disk Unmounted('disk1')
disk1 device will attempt to be mounted ...
***Disk Appeared ('disk1',Mountpoint = '', fsType = 'cddafs', volName = 'Audio CD')
Disk Mounting Completed
-n Grabbing entire CD - tracks:
000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013 000014 000015 000016
Selected: #1
---- Gene Ammons Quartet / The Gene Ammons Story: Gentle Jug ----
1: Till There Was You
2: Answer Me, My Love
3: Willow Weep For Me
4: Little Girl Blue
5: Something I Dreamed Last Night
6: Something Wonderful
7: I Remember You
8: Someone To Watch Over Me
9: Two Different Worlds
10: But Beautiful
11: Skylark
12: Three Little Words
13: Street Of Dreams
14: You'ld Be So Nice To Come Home To
15: Under A Blanket Of Blue
16: I'm Glad There Is You
-n Edit selected CDDB data? [y/n] (
-n n):
n
-n Is the CD multi-artist? [y/n] (n):
n
/Users/u1/bin/abcde: line 2731: -n: command not found
Grabbing track 000001: Till There Was You...
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-pvX] source_file target_file
cp [-R [-H | -L | -P]] [-fi | -n] [-pvX] source_file ... target_directory
The following commands failed to run:
readtrack-000001: cp -f returned code 64
Finished.



[ Reply to This | # ]