How to burn bin/cue file pairs

[strobe]

I compiled cdrdao for Mac OS X. This can burn bin/cue files very easily. The only cue/bin pair which haven't worked for me thus far had spaces and hyphens in the filename. Changing the filename and editing the cue file to reflect that solved the problem.

You can download my binary from here:

http://homepage.mac.com/anarkhos/.Pictures/cdrdao.tgz

The command is used thusly:

Insert a blank CD, tell the finder to ignore the CD and continue.

type:
sudo ./cdrdao write -device IOCompactDiscServices blah.cue

If run as root cdrdao will use high priority threads to avoid underruns.

If you have a DVD burner you would use "IODVDServices" instead.

If your CD-R isn't known (like mine wasn't) you can select a specific driver. For example this is in my .tcshrc file:

alias cue sudo /Users/anarkhos/cdr/cdrdao write --device IOCompactDiscServices --driver generic-mmc

thus to burn anything I just type "cue blah.cue"

 

[ulrik]

Yehaa, million thanx for the info, I have been looking for this for quite some time now

 

[buggs1a]

why not do what most mac users need and expect? no command line, only gui. like drag n drop a cue file on the app and it launch and burn etc. or have it open, drag n drop like in toast or something simple. cli is WAY to hard for 99% users and some won't even touch cli. i have vowed never to use the command line.

 

[strobe]

buggs, I didn't write this software nor am I selling anything. This is an FYI. If this is not what "most mac users need and expect" what pray tell is my incentive?

If you want what you ask for, go bug Roxio. <insert middle finger here>

 

[ulrik]

By not using the terminal, you give away the true control over your OS X system.

 

[strobe]

Originally posted by ulrik
By not using the terminal, you give away the true control over your OS X system.

I couldn't disagree more. There are tons of things which I can control in OS X which cannot be done in the terminal. The only reason I find the terminal useful is because a lot of other people use that interface. It isn't any more low-level than a graphical app, it's just an arcane interface for some programs that often chokes when filenames have spaces, hyphens, or non-ascii characters.

cdrdao isn't any better as a command line program, get over yourself.

 

[ulrik]

tell me what you think can't be done with the terminal and I guess I am able to tell you how to do it (as far as you don't say "minimize this window from the finder"

PS: you said the terminal doesn't have more influence than a GUI app. This is true, but what if there is no GUI app for what I have to do with my system? Also, executing the command in the terminal is most often much faster then starting an app and using a GUI.

 

[strobe]

It may sometimes be faster to type a specific sequence of keystrokes than a specific sequence of mouse clicks, but determining that sequence of keystrokes will usually take longer.

The primary advantage of a GUI is familiarity. A certain appearance implies a behavior, or at least used to in Mac OS. The advantage can still be had in OS X if you only use Carbon apps (or I guess only Cocoa apps or only Java apps). What I'm saying is merely fact that an app is graphical in no way an indicator how easy it is to use. X11 apps for example are pure hell. There is nothing about the X11 'interface' which implies anything. When using UNIX I prefer to stick to the command line despite the fact that every command has its own arcane syntax.

Another problem with the command line is there is no runtime, instead everything is file-based. Consider a package of commands like GRASS where one command doesn't know what the other is doing (no runtime). Some time ago I was working on a GUI for this horrid system and decided that without a runtime it was folly to even pretend a graphical interface was practical. One couldn't even implement undo. Another problem with everything being a file is if you decide to move or rename a file or directory, things break. In MacOS the path of a file isn't important (Apple long since depricated toolbox functions using paths). An open file can be moved or renamed and the reference the program uses to access the file doesn't change. In UNIX the path of a file is considered constant. This has human interface implications--you have to keep in mind which files are open in all UNIX, Java, and many Cocoa apps if you decide to rename or move a file/folder/non-root volume which will change the path.

It's no surprise to me that virtually no UNIX users understand the issue at hand.