strangehours: The weekend's hacking effort: cdparanoia for OSX

Tobias Sargeant (

strangehours) wrote,
@ 2003-10-23 09:35:00

Current music:

Neuroticfish - Velocity

The weekend's hacking effort: cdparanoia for OSX

Motivated by a powerbook cdrom drive that's becoming flakey with age, I ported cdparanoia to OSX. I've mailed the authors of cdparanoia about the port, but haven't received a response. I believe because it's GPLed, I don't actually need permission to distribute it, so here it is:

cdparanoia for OSX

Several sources of information were used in the process, which some people might find interesting:

libcdio: This would have been much cooler if it exposed OS independent access to the CD TOC. If that were the case, I could have come up with a version that still ran on linux. As it stands, this version of cdparanoia will *only* compile on OSX. libcdio is a cool idea though, and really deserves some good press.
bochs: Bochs has OSX source for cd drive emulation on OSX. It's slightly better structured than the libcdio source code, and was useful for teasing apart the strange darwin driver model.
Apple device driver information

Update, for those running 10.3

This patch is needed to compile on Panther

(Post a new comment)

	kineticfactory 2003-10-23 02:35 am UTC (link)
	Have you thought of doing a talk on the port and the issues involved in device programming on OSX, or of writing a tutorial on the subject? I think either of those would be well-received. (Reply to this) (Thread)

	strangehours 2003-10-23 07:10 pm UTC (link)
	I know next to nothing on the subject. So, no... Not really. I haven't even got a firm handle on how to use device interfaces from userspace yet (the CD driver has an ioctl based API which I'm comfortable with, but I think you can also do interesting things with a COM-like interface that's exported directly). (Reply to this) (Parent)

	10.3 (Anonymous) 2003-11-24 09:49 pm UTC (link)
	Do you have this working in 10.3? I do a 'make configure' 'make' and it fails in the compile phase. (Reply to this) (Thread)

	Re: 10.3 strangehours 2003-11-24 10:09 pm UTC (link)
	On 10.3 it configures fine for me, but doesn't build correctly. Looks like the BSD driver layer may have changed somwhat. I'll do some investigation. (Reply to this) (Parent)(Thread)

Re: 10.3

strangehours
2003-11-24 10:22 pm UTC (link)

Ok, this patch makes cdparanoia compile for me on 10.3. The method you should use (if you want it in the default location of /usr/local/bin) is:

$ ./configure
...
$ make
...
$ sudo make install

(Reply to this) (Parent)(Thread)

	Re: 10.3 (Anonymous) 2003-11-25 08:55 pm UTC (link)
	Fabulous, that works great! Have you considered submitting this as a 'package' to fink? I'm sure they would love to see it. (http://fink.sourceforge.net/) (Reply to this) (Parent)(Thread)

	Re: 10.3 strangehours 2003-11-25 10:21 pm UTC (link)
	Unfortunately I know nothing about making debian (or fink) packages. It's also a bit of a quick hack, so I'm not totally sure that it's stable. I guess it'd be good to get it out to the wider public, though. I'll think about it... (Reply to this) (Parent)

	Re: 10.3 (Anonymous) 2004-01-30 11:33 am UTC (link)
	hi can you please tell how I should use the patch ? - Ram (Reply to this) (Parent)

	Thankyou! cheesyhill 2003-12-22 01:00 pm UTC (link)
	Wow, this is really cool! I'm a bit of a bigot with ripping and I was never that confident of the iTunes ripper; cdparanoia rules. You really should think about putting this into fink. I was most disappointed when apt-get install cdparanoia didnt work. I think people would be happier with something that 'seems to work but isn't fully tested' than google -> compile from source. (Reply to this)

Applying Patch
(Anonymous)
2004-01-30 04:28 pm UTC (link)

Sorry if I'm being a dummy, but could you please tell me how to apply the patch correctly (e.g. what file to apply it to, etc). I've tried having the patch and the cdparanoia directory in the same directory and running

patch < cdparanoia-panther.diff

but i get this output:

can't find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -rud cdparanoia-0.9.8/include/cdparanoia/paranoia/p_block.h cdparanoia-0.9.8-new/include/cdparanoia/paranoia/p_block.h
|--- cdparanoia-0.9.8/include/cdparanoia/paranoia/p_block.h Mon Oct 20 13:31:35 2003
|+++ cdparanoia-0.9.8-new/include/cdparanoia/paranoia/p_block.h Tue Nov 25 17:14:34 2003
--------------------------
File to patch:

I've tried moving the patch into the cdparanoia-0.9.8 directory directory but the same thing happens. I think the problem is that I don't know what I'm doing! Any pointers?

Thanks,
Aaron

(Reply to this) (Thread)

Re: Applying Patch

strangehours
2004-02-02 09:39 am UTC (link)

Try untarring the tarball, cd'ing into the directory, and typing:

patch -p1 < /path/to/patch/file

(Reply to this) (Parent)(Thread)

	Re: Applying Patch (Anonymous) 2004-02-10 12:52 pm UTC (link)
	That did the trick. Thanks so much! --Aaron (Reply to this) (Parent)

Thanks for trying, but...
(Anonymous)
2004-02-01 07:36 pm UTC (link)

Thanks very much for doing this port - I've been looking for something superior to iTunes or whatever for a long time. Ripping a CD on my first generation G4 (with DVD-RAM drive) has always given me files with lots of audible clicks and pops. Using the new "error correction" in iTunes has improved the situation a bit, but I get much better results with my G4 powerbook.

Anyway, I tried your port of cdparanoia today with great hope. (Even compiled first time with the panther patch). However, despite the fact that I know my drive has problems, cdparanoia shows no errors at all when reading the files (using cdparanoia -Bf):

outputting to track01.cdda.aiff

(== PROGRESS == [ *| 018691 00 ] == :^D * ==)

So, I tried ripping the same CD twice and comparing the results, here's what I saw:

[Gavin-Aikens-Computer:~/Desktop] gavin% diff -s 1 2
Binary files 1/track01.cdda.aiff and 2/track01.cdda.aiff differ
Binary files 1/track02.cdda.aiff and 2/track02.cdda.aiff differ
Binary files 1/track03.cdda.aiff and 2/track03.cdda.aiff differ
Binary files 1/track04.cdda.aiff and 2/track04.cdda.aiff differ
Binary files 1/track05.cdda.aiff and 2/track05.cdda.aiff differ
Binary files 1/track06.cdda.aiff and 2/track06.cdda.aiff differ
Binary files 1/track07.cdda.aiff and 2/track07.cdda.aiff differ
Binary files 1/track08.cdda.aiff and 2/track08.cdda.aiff differ
Binary files 1/track09.cdda.aiff and 2/track09.cdda.aiff differ
Binary files 1/track10.cdda.aiff and 2/track10.cdda.aiff differ
Binary files 1/track11.cdda.aiff and 2/track11.cdda.aiff differ
Binary files 1/track12.cdda.aiff and 2/track12.cdda.aiff differ
Binary files 1/track13.cdda.aiff and 2/track13.cdda.aiff differ
Binary files 1/track14.cdda.aiff and 2/track14.cdda.aiff differ
Binary files 1/track15.cdda.aiff and 2/track15.cdda.aiff differ
Binary files 1/track16.cdda.aiff and 2/track16.cdda.aiff differ
Binary files 1/track17.cdda.aiff and 2/track17.cdda.aiff differ
Binary files 1/track18.cdda.aiff and 2/track18.cdda.aiff differ
Binary files 1/track19.cdda.aiff and 2/track19.cdda.aiff differ

So, with a 19 track CD, it didn't get any of the tracks the same in two tries. I guess something went wrong in the port!?

regards,
Gavin

gavin at aiken84 dot freeserve dot co dot uk

(Reply to this) (Thread)

Re: Thanks for trying, but...

strangehours
2004-02-02 09:36 am UTC (link)

From the cdparanoia FAQ:

Why do the binary files from two reads differ when compared?
The problem is the beginning point of the read. Cdparanoia enforces consistency from whatever the drive considers to be the starting point of the data, and the drive is returning a slightly different beginning point each time. The beginning point should not vary by much, and if this shift is accounted for when comparing the files, they should indeed turn out to be the same (aside from errors duly reported during the read; scratch correction or any reported skips will very likely also result in different files).

This may be what you're seeing. Listen to the files. If they're corrupted, please tell me. I'm pretty certain that I haven't got anything wrong but in software, anything can, and probably will, happen.

(Reply to this) (Parent)(Thread)

Re: Thanks for trying, but...
(Anonymous)
2004-02-02 10:25 am UTC (link)

Righto, I'll have a careful listen to them tonight - I have to admit I didn't actually do that last night. Hadn't read the FAQ either before I posted, very naughty.

I was trying to find a meaningful way of comparing the binary files too - any ideas? 'cmp -l' is useless as if the streams are out of sync at all you will get the apparent result that the files differ at every point. The best I could come up with was 'diff -a file1 file2 | wc -l' - if you look at the output from diff -a you can recognise patterns in the data and I could spot apparent errors or differences between the two versions. diff should be able to cope with files that are almost the same but have the odd extra bit or missing bit (due to jitter?), in a way that cmp couldn't (at least I think so - never really tried using diff in this way on a binary file before!). This was coming up with around 20-30 "lines" of diffs between the two files, which I think is too many for it just to be due to differing start points in the files. I guess what I should do is dig out a PC with linux, compile cdparanoia for it, rip the same files, and try the same diff tests!?

For comparison, I also tried several other methods of ripping the same tracks - Finder copy to the HD, and iTunes with and without error correction (and with the file format set to aiff). In each case, the diff -a | wc -l comparison came up with similar kind of results - between 10 and 30 diffs between each file. None of the methods seemed to be statistically better than any of the others, if the diff -a comparison is valid (which I'm not saying it is, just couldn't come up with any better!).

Interestingly, doing the diff between two different methods of ripping the file (eg between cdparanoia and Finder copy) came up with massively more differences (except in the case of comparing iTunes with and without error correction). I couldn't really see why that would be either - surely the aiff files should have been similar in each case? Or am I missing something?

(Reply to this) (Parent)(Thread)

Re: Thanks for trying, but...

strangehours
2004-02-02 10:43 am UTC (link)

You'll always get a multiple of one sector's worth of data shifting. If you chop the files up into blocks of 2352 bytes, make md5sums of each block, and then diff the two lists of sums, you'll get a good idea of whether the differences occur in the middle of the files rather than the ends.

Try:

split -b 2352 file1.cdr file1_split; md5sum file1_split* > file1.list; rm -f file1_split*
split -b 2352 file2.cdr file2_split; md5sum file2_split* > file2.list; rm -f file2_split*
diff -u file1.list file2.list

You'll need to use .cdr files, so that there are no file headers.

(Reply to this) (Parent)(Thread)

Re: Thanks for trying, but...
(Anonymous)
2004-02-03 12:01 am UTC (link)

Think I'm being dim but I couldn't see which option would give me a .cdr file?

Anyway, I brought a PC laptop home this evening and have been comparing results of various ripping methods on that, using the compare wav tool in Exact Audio Copy (which seems a lot more effective than home-brew solutions using diff!). I ripped the same 10 minute track (to wav) in EAC, your port of cdparanoia on my G4 desktop, and iTunes with and without error correction on my desktop and G4 laptop.

The results are quite interesting - I have them collated in a pdf, but in summary all the samples differed at the start (I presume this is due to different offsets when starting the rip), the EAC rip and the G4 laptop iTunes rips were otherwise identical (with and without error correction - unless perhaps it had cached it after the first rip), and on the G4 desktop iTunes had only 3 single byte missed samples with error correction turned on. Without error correction it was another story - it had 3 single byte misses plus one 14 byte and one 11 byte miss. Sadly, cdparanoia seemed to come out the worst - it had three 12 byte misses, one 13 byte miss, four 12 byte repeats, and one 6 byte repeat. Subjectively I could hear slight pops around the time markers indicated at some of the faults, although not all. Oddly I thought I could hear one or two pops in the EAC rip even, but the desktop iTunes and cdparanioa rips did sound worse.

So, sorry to be the bearer of bad news but it does seem that there's a problem with it. Let me know if there's anything you want me to try.

(Reply to this) (Parent)(Thread)

	Re: Thanks for trying, but... strangehours 2004-02-09 04:21 am UTC (link)
	Ok, so there's definitely a problem there. I can't think of any obvious causes of this behaviour, or, indeed, any good way of debugging it (given the flakiness of my hardware). Did you try it multiple times? I'd be interested to know how reproducable it is or isn't. Thanks for the testing, by the way. (Reply to this) (Parent)(Thread)

Re: Thanks for trying, but...
(Anonymous)
2004-02-09 05:43 pm UTC (link)

I only tried it the once, I can try it again with multiple different CDs some time soon. Probably the best test is to compare the cdparanoia results with EAC on the PC, I guess? (have to take the horrible PC home from work again then!)

When you run cdparanoia yourself, does it apparently come up with a "clean" rip each time - ie as the progress bar moves across, do you get all spaces, or do you get some '-', '+' or other errors reported? It was the apparently clean rips every time that alerted me to a possible problem - I would expect that on my desktop system, with a known dodgy CD drive, that I would get at the very least a few -/+/!/e symbols (if not some V's) on each rip.

(Reply to this) (Parent)(Thread)

Re: Thanks for trying, but...

strangehours
2004-02-09 10:45 pm UTC (link)

No, my rips weren't clean at all. In fact I was getting unrecoverable errors, which was hen I decided that my CD drive was on the way out.

No need to rip multiple times on the PC or multiple CDs. Assume that the one EAC rip is the gold standard and take a few measurements relative to that. I'm mostly interested to know if the errors and/or error rates that you saw on the mac for various ripping strategies are repeatable.

(Reply to this) (Parent)

	sneakums 2004-08-23 09:40 am UTC (link)
	This works really well. Thank you for doing this! (Reply to this)

	thank the gods (Anonymous) 2004-10-03 01:03 am UTC (link)
	i was hoping there was some simple way to get this to work on osx! i just switched from the windows world, and boy is it hard to find opensource programs that do what i want to do on osx. such as office spreadsheet programs or word processing for example. thank you very much! (Reply to this)

woody77
2005-03-16 01:41 am UTC (link)

Amazing what turns up on LJ...

Anyway, it appears you based your work off of 3.9.8? I've to create a package for Gentoo's portage on osx for this, and a quick diff of the two sets of source (the base 3.9.8 source and your tarball) show some substantial differences (wish I had a better osx diff tool than diff, I'll probably do this on my win2k box using examdiff).

But was wondering if you had the ability to easily make a patchfile to go between the standard code you're based on, and your new code. Then making a macos build for portage would be easy (patchset applied after untarring the source).

If not, I'll try to figure out what you changed, file by file, and make it work.

Any luck on the potential problem with not getting clean rips?

Also, do you know any way around the sector start for tracks issue? I thought that tracks had to start/end on hard sector boundaries (multiples of the 2352 that you mentioned above?)

And thanks for the work on this.

Feel free to e-mail me directly at my lj-username @ gmail.

(Reply to this) (Thread)

	Please help me. (Anonymous) 2005-06-13 07:49 am UTC (link)
	Help me please, I'm new with Mac and I don't have a clue how to make this work. Can someone go through the things I need to do to make it work? PS: EMI sucks :) (Reply to this) (Parent)(Thread)

	Re: Please help me. strangehours 2005-06-13 11:30 am UTC (link)
	Hi, I think a number of people have done ports of cdparanoia now, all of which I'm sure are better than the quick hack that I came up with. (Reply to this) (Parent)(Thread)

	Re: Please help me. (Anonymous) 2005-06-22 10:40 am UTC (link)
	Can you name some names? Which do you prefer or recommend? Thx! (Reply to this) (Parent)(Thread)

	Re: Please help me. morsknorsk 2006-01-14 09:57 pm UTC (link)
	http://www.buserror.net/cdparanoia/ (Reply to this) (Parent)

	Binary Installation Package (Anonymous) 2005-07-04 05:20 pm UTC (link)
	I've put together a OS X installation package based on this port: http://www.bronsonbeta.com/downloads/cdparanoia-0.9.8.dmg Stefan www.bronsonbeta.com (Reply to this)

	aoichan 2006-01-21 08:45 pm UTC (link)
	Thank you for this! I've been looking all day for something that'll let me rip sectors under track 1/ tim eindex 0:00. Do you think you could make the syntax easier someday, though, and just specify ripping by the range of sectors? I know it's not totally accurate but I wound up having to use something like 'cdparanoia "1[:00.00]-1[01:02]" --toc-offset -4575'. (Reply to this)

	Works on Tiger/MacBook Pro (Anonymous) 2006-07-06 06:47 pm UTC (link)
	I know I'm late to the party, but thought you may be pleased to know that this port works (with the 10.3 patch) on a MacBook Pro (Intel) and Tiger (Mac OS X 10.4). Thanks! (Reply to this)

	Options missing (Anonymous) 2007-06-01 08:29 pm UTC (link)
	First of all, thanks for this, it works great. However, removing the options "-d" and "-g" breaks (the CD ripping and encoding script) abcde for me, since abcde tries to specify a device for cdparanoia. Just thought I'd let you know. What is the current behavior if there is more than one CD device anyway? Lukas (Reply to this) (Thread)

Re: Options missing

strangehours
2007-06-03 09:45 am UTC (link)

It wouldn't be hard to add the options back in. As I remember, at the time it didn't seem to me like there was any way to get a list of optical drives, or to select one in particular. There must be a way, however; I just never found it. You could quite easily provide faked -d and -g options that did nothing/listed a single drive.

Having said that, iTunes now has paranoia like cd reading, and I have a new mac with a functioning drive, so it's kind of dropped off my radar a bit.

(Reply to this) (Parent)

	rspeed 2009-02-11 04:52 pm UTC (link)
	Any mirrors for this? The host is down. (Reply to this)

	cdparanoia-10.2 upintheclouds 2009-05-31 09:07 pm UTC (link)
	I've used this work to put together a patch against cdparanoia-10.2 ... you can just download cdparanoia-10.2 from upstream and apply this patch (or just install it from MacPorts): https://trac.macports.org/browser/trunk/dports/audio/cdparanoia/files/osx_interface.patch?rev=51693 (Reply to this)

Username:		Create an Account Forgot your login or password? Login w/ OpenID
Password:
	Remember Me
	English • Español • Deutsch • Русский…

About

Help

Get Involved

Legal

Store

LJ Labs