Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Rip Audio CD to Flac & Burn From Flac + toc

Share your HowTo, Documentation, Tips and Tricks. Not for support questions!.
Message
Author
User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

Rip Audio CD to Flac & Burn From Flac + toc

#1 Post by julian67 »

This Howto is for Debian Lenny but should work equally well in any version of Debian from Etch onwards.

The howto is aimed at Debian users of any level who like to use the terminal, appreciate automation and like to hear the music the way it was on the original CD. I'm assuming you've used various CD rippers and know why you don't like them and are at least vaguely familiar with CDDB/freedb and audio tagging.

Objectives

1: Rip an audio CD, without loss of audio quality, to individual tracks.

2: Losslessly compress the ripped audio and number, name and tag the files.

3: Be able to use those files to burn an audio CD that sounds identical to the original and plays in any CD player.

4: Be able to do this on any GNU/Linux distribution and regardless of Desktop Environment/Window Manager etc.

5: Get it set up so you don't have to remember stuff!

The aim is to extract the digital audio, to store it using lossless compression to save disk space and to be able to burn a CD which sounds identical. The copy must have no audio defect. It must have the same gaps between tracks as the original if there are gaps on the original. If the original was gapless the copy must also play back identically on a regular home/car/personal CD player.

The aim of this howto is not to make a bit for bit identical copy of the physical CD. It is only concerned with the audio.

If you need to back up non-audio content or you worry about hearing the difference between 0.25 and 0.3 seconds of silence at the end or at the beginning of your audio CDs then this howto is not for you. You may be happier using cdrdao to make bin+toc and forgoing the space saving of lossless compression.



Advantages & Disadvantages of this Method


Disadvantages:

It doesn't deal with mixed-mode CDs (though it probably could be adapted to do so), or with anything other than the audio. If you want that Sony XCP copy protection and win32 rootkit preserved, or if you like to play your heavy metal CD backwards to hear messages from the devil in hidden sectors then this method won't work.

When you're ready to burn a CD from your archive you need to convert the flacs to wav. Luckily this is very fast and a no brainer, flac -d *.flac, but it might be considered an extra step.

One package needs to be compiled from source because the version in the Debian repos has a serious bug[edit: FIXED in Squeeze & Sid]. Fortunately it's a 100% straightforward install which I'll outline for those who are not used to installing from source. The bug has been reported in Debian's bug tracker, is already fixed upstream, and at some point the fixed version should arrive in Debian.

Advantages:

Instead of a toc+bin (cdrdao) cue+flac (K3B and others) or flac with embedded cue (abcde) this method gives you a set of individual flac files, numbered, named and tagged as you like, which are usable in your favourite audio player software, in your home audio flac player, and possibly even in your portable audio player. They can be used on any general purpose OS, such as Windows 98/ XP/Vista or Mac OS 9/OS X, without restriction or difficulty or compatibility issues.

You can even use this method to simultaneously produce mp3/ogg/aac files as well as the flacs relevant to this howto.

Lossless compression: You could use cdrdao to make a toc+bin and compress the bin with gzip or bzip2. But regular compression tools will only get you a file something like 90% the size of wavs or a cdrdao bin. Flac will easily compress wavs to about 55% of their original size (typically).

Normal burning methods introduce an ugly and unwanted gap between audio tracks. Yuk! Because this method uses a toc file and the CD is burned in dao/sao mode the resulting CD sounds just like the original. For CDs composed of individual tracks this doesn't really matter but many albums have the music flow from one track to the next with no audible break.

Everything is done using free(dom) software and there is no need for wine or win32/proprietary binaries. The tools are hosted in Debian main.

A powerful computer is not required. It doesn't matter if you run Gnome, KDE, Xfce, Ratpoison, Fluxbox or work from a serial terminal. This is all done in the terminal and is quite suitable for modest machines and machines which don't run X. But if you do have a multi-core beast the encoding can take advantage of multiple cores/threads, the number being set by the user.

Once set up, the user only has to remember a one word command 'ripit' to rip the CD. The process of producing an audio CD will be almost as simple.

The Tools

We're going to use Ripit for extracting the CD audio (ripping), Flac for losslessly compressing the audio and cdrdao for burning audio CDs.

As well as ripping the CD, Ripit also handles creating the directories for the resulting files, encoding the audio to flac, naming and tagging the files and producing a toc file. A toc is a Table Of Contents. It's the toc which allows cdrdao to write to a blank CD and have the tracks laid out exactly as they were on the original.

Install cdrdao and flac

Code: Select all

# apt-get install cdrdao flac
Install Ripit

**edit July 2009 ** the ripit version in Squeeze is now fine as it is, no need to build it.

Ripit exists in Debian main as version 3.6.0-1 but it has a bug with CDDB lookups. This is fixed in the upstream version which can be obtained from http://www.suwald.com/ripit/news.php I use ripit-3.7.0-beta20090308 and recommend you do the same until a fixed version appears in Debian repos.

Install Ripit's dependencies:

Code: Select all

# apt-get build-dep ripit
Now unpack/extract your downloaded ripit source package, navigate into the directory ripit-3.7.0-beta* and install ripit:

Code: Select all

# make install


edit: a better method now that the new version is in Squeeze would be to download the source from Debian Squeeze repos using 'apt-get source' and then build a proper Debian package. I didn't check if all the depends can be met from Lenny, suck it and see.

Configure Ripit

Ripit works best when used with a config file ~/.ripit/config

With a config file in place you don't have to remember anything except the command 'ripit' :D

Code: Select all

$ mkdir ~/.ripit
We'll leave the default config in place and untouched in /etc/ripit but copy it to ~/.ripit/ where ripit will use it in preference to the default.

Code: Select all

$ cp /etc/ripit/config ~/.ripit/
The following config file for this Howto has all the commented lines removed for the sake of brevity and the options are set with this howto in mind. It should work for almost everyone and you can probably just copy it and use it as ~/.ripit/config but check that your CD drive is indeed /dev/cdrom and change that if necessary and if you are behind a proxy you'll need to read the original config comments and add your details accordingly.

You might also prefer to set a different directory/naming scheme,

I very strongly advise you to look through and amend and use the original config file. It is extremely well commented and will show you what a versatile tool Ripit is. You can encode simultaneously to multiple formats, have the encoded files output to different locations according to their format, you can have remote machines do the encoding and many other options . But that's all outside the scope of this howto.

It's essential for the purpose of this howto that the following options are as seen in the following example:

cdtoc=1

ripper=1

paranoia=1

encode=1

coder=2

normalize=0

Don't worry about the unset options. The script expects to see them and their presence simply avoids seeing error messages.

This config is ideal for batches of CDs. 'eject=1' means the CD will be ejected as soon as the audio is extracted and 'loop=1' means ripit will just keep on going as long as you feed it another CD when you see the tray eject. You can change either of these options by changing the 1 to 0.

If you're happy to use the names and tags the CDDB lookup produces then you can also set 'interaction=0' and even 'verbose=0' and have the whole process run entirely silently and with no action needed except putting another CD in the tray and pushing it shut.

Code: Select all

cddevice=/dev/cdrom
output=
dpermission=0755
fpermission=
ripper=1
ripopt=
paranoia=1
ghost=0
prepend=2
extend=2
encode=1
coder=2
qualame=
lameopt=
vbrmode=
bitrate=128
maxrate=0
preset=
qualoggenc=3
oggencopt=
quaflac=5
flacopt=
quafaac=100
faacopt=
dirtemplate="$artist - $album"
tracktemplate="$tracknum - $trackname"
infolog=
lowercase=0
underscore=0
chars=
playlist=2
year=
comment=
utftag=1
CDDBHOST=freedb.org
mirror=freedb
transfer=cddb
proto=6
proxy=
mailad=
archive=0
submission=1
interaction=1
lcd=0
lcdhost=localhost
lcdport=13666
sshlist=
scp=0
local=1
verbose=3
eject=1
ejectcmd=eject
ejectopt={cddev}
loop=1
halt=0
nice=0
nicerip=0
threads=1
md5sum=0
wav=0
normalize=0
normopt=-b
cdtoc=1 
Let it Rip!

So now you have ripit installed and configured it's time to rip a CD. I'm using The Beatles Abbey Road because it has many tracks which run seamlessly together with no gap. This makes it a good test because many software audio players, personal mp3/ogg players and CD burning applications will still fail to handle this well, even 25+ years after the audio CD and 20 years after the CD-R.

Code: Select all

$ ripit
Yes, that's it!

You will be prompted to confirm the CDDB lookup looks good and be asked if you would like to change anything. Ripit will then produce a directory containing numbered, named, tagged flac files along with an .m3u playlist and a file named cd.toc

Keep the flac file names intact. You can edit the tags but if you change the actual filename you'll need to change the corresponding name in the cd.toc


Burn It!


The cd.toc is the key to a successful burn. You can see that it describes the filenames of the ripped tracks and contains some CD-Text information. The most important thing is that the files it describes are .wav files not .flac files, so before burning an audio CD those flacs will need to be decompressed back to .wav.

You can also see that there is some helpful info included:
Use command >cdrdao scanbus< to detect device.

Assume the device found is: ATA:1,0,0, then, use e. g. command
>cdrdao write --device ATA:1,0,0 --speed 4 cd.toc< to burn the CD.
Quite helpful! You don't even need to remember which application to use or how to use it, the reminder is there for every CD you rip.

If you only have one optical drive then don't worry about the --device parameter, it should be automatically detected. The --speed 4 option reduces the write speed to a max of 4x. This is far less important than it used to be but is a safe default. On a modern burner with high quality media burning at maximum speed is no problem, in fact will produce fewer write errors than if the speed is very low. Your mileage may vary, if in any doubt stick to 4x.

If you have several devices then as root:

Code: Select all

# cdrdao scanbus
and choose your preferred device and specify it as outlined in the cd.toc

The great thing about cdrdao is that it writes the Disk At Once (dao, also known as sao - session at once), instead of writing it track by track. It will not introduce any artifical gaps between tracks. It's used by many CD writing applications such as K3B in KDE and EAC in Windows. It can be installed and used on more types of computer than you've likely ever heard of. It's ideal!

Assuming we're in the folder containing the flacs and the cd.toc we just need to decompress the flacs to wav:

Code: Select all

$ flac -d *.flac
and now burn:

Code: Select all

$ cdrdao write --device <your_device_here> --speed 4 cd.toc
Actually I'm lazy and forgetful, I don't want to remember any of this, so I've aliased it in ~/.bashrc and also set it up to remove the wavs after the burn completes:

Code: Select all

##### decode & burn flacs+cd.toc to CD ######

alias burnit='flac -d *.flac && cdrdao write cd.toc && rm *.wav'
After you edit .bashrc run

Code: Select all

source ~/.bashrc
so the changes are immediate.

So now I can just run

Code: Select all

burnit
and 5 minutes later I have an audio CD, complete with CD-TEXT, ready to play and the wavs are deleted.

Moment of Truth

I play the CD in my old Sony CD portable. Track 9 "You Never Give Me Your Money" has a fairly quiet last 10 seconds with some ambient sounds and on the original CD merges seamlessly into track 10 "Sun King". If the ripping and burning process has introduced any artificial gap or pop or click it will be horribly obvious here......Success! It's perfect :D I also checked the CD in my Sony CDP-XE570 (a "proper" hi-fi CD separate).

Note about gapless playback of audio CDs on computers

Check your burned CD on a CD player not a computer!

Unfortunately playing a gapless audio CD gaplessly on a computer isn't so simple. Almost every CD capable media player/audio player can play back mp3 gaplessly (some still can't) but not audio CDs. Many (most!) portable mp3 players fail even at this. I booted into Windows to see how simple this is in Vista. I used a retail CD, not a burned copy. I was convinced Winamp would play it perfectly. No it couldn't! There was a small but distinct gap between tracks which should have flowed one into the next. Windows Media Player handled it perfectly, an ability it has had since WMP9 (comparatively recent) and foobar2000 was fine as well. How about in GNU/Linux? It's even worse. I didn't find a single player which can play a CD exactly as a CD player plays it. Rhythmbox can't, Kaffeine can't, VLC can't, Totem apparently can no longer play CDs at all with gstreamer or xine :shock: , Xine can't. It's claimed that Aqualung can do this but on my system it crashes as soon as it starts up :roll: When you see claims that a player is capable of gapless playback look again because it usually doesn't include CDs. I've even read bug reports where the user files a bug because his/her audio CD is not played back gaplessly and the developers/maintainers close the bug because they support gapless mp3 and refuse to acknowledge that gapless CD playback matters or is a different issue. VLC devs simply say it isn't an aim. Anyway at least we can rip and burn them without error :-)

CD-Text

The combination of ripit and cdrdao will produce an audio with CD-Text if the CD is burned with a CD-Text capable drive. cdrdao should automatically use the best driver for your device. If you know that your burner is CD-Text capable but it's producing CDs with no CD-Text then please have a look at CD-TEXT Burning on Linux which may be useful. It solved the problem for me.

Summary

This rather long howto results in the following process for ripping, backing up and burning your precious collection of audio CDs:

Code: Select all

$ ripit

Code: Select all

$ burnit
8)

edit: link to ripit updated
Last edited by julian67 on 2010-09-15 12:37, edited 9 times in total.

jalu
Posts: 1389
Joined: 2008-11-19 23:26

#2 Post by jalu »

hello julian67,
just a thanks from me, that was fast.
i guess that will be a good guide for lots of people starting, as its pretty elaborate.
greetings
(i`ll try during this week, but see no problem with such a guide)

jalu
Posts: 1389
Joined: 2008-11-19 23:26

#3 Post by jalu »

everything went fine with ripping and burning
(maceo parker and frank zappa).

quote from the how-to:
"Code:
$ flac -d *.wav"
might be there`s a typo? i used "flac -d *.flac" as in the other examples and it worked.

theres an option for abcde to override the default:
`abcde -o wav, flac`
(for example).
is there a similar thing in ripit?
(well, i`ll find that out on my own)

great howto,
thanks for that

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#4 Post by julian67 »

jalu wrote:everything went fine with ripping and burning
(maceo parker and frank zappa).

quote from the how-to:
"Code:
$ flac -d *.wav"
might be there`s a typo? i used "flac -d *.flac" as in the other examples and it worked.

theres an option for abcde to override the default:
`abcde -o wav, flac`
(for example).
is there a similar thing in ripit?
(well, i`ll find that out on my own)

great howto,
thanks for that
Yes there was a horrible typo! Thanks for pointing it out, it's now corrected.

If you want to run ripit just to output wavs it's easy. Edit ~/.ripit/config
from

Code: Select all

encode=1
to

Code: Select all

encode=0
and

Code: Select all

wav=0
to

Code: Select all

wav=1
If you read through the commented config file you can see all kinds of possibilities. One of the reasons I chose ripit for this howto, and why I use it, is that it has the sanest set of options of any similar tool and all those options are commented and explained much more clearly than others. abcde is fine but I couldn't do everything I wanted and doing some things was like solving a puzzle. I think Ripit combines incredible versatility, easy compatibility with cdrdao and also adheres to the K.I.S.S (keep it simple, stupid!) approach.

But if you just want to make a straight CD to CD copy I'd suggest using cdrdao exclusively. If you have only one optical drive it should be as simple as

Code: Select all

$ cdrdao copy
which will cause cdrdao to rip the CD using cdparanoia in mode 3 (best error detection/correction) by default, write a .bin to your hard drive and then eject the tray, accept a blank and burn it. It's a fantastic tool. If you want your duplicate to include CD-Text you simply run

Code: Select all

cdrdao copy --with-cddb
Wisdom from my inbox: "do not mock at your pottenocy"

jalu
Posts: 1389
Joined: 2008-11-19 23:26

#5 Post by jalu »

thanks for the additional info,
i grabbed my info`s on abcde/wodim from here and there
(the dark side 'uaahrg')
so its all a bit confused/lack of based knowledge. (once the wav is removed, i had to burn with k3b, etc).

just for fun i took the test-version 3.7 of ripit, the author is asking for comment.
well: i used it for 4 times now, but i can see no problems. If there are,
i`ll ask here.

greetings

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#6 Post by julian67 »

The beta of ripit seems excellent to me, I've been using it for 6 months or so. The older version was fine but some of the dependencies changed the way they do things so the maintainer updated the script and made some nice enhancements like directory naming by suffix the same as in abcde.
Wisdom from my inbox: "do not mock at your pottenocy"

curly
Posts: 8
Joined: 2009-04-06 19:28

#7 Post by curly »

I've just finally gotten abcde to run as a daemon (and maybe init.d script).

I'm trying to adapt the init / daemon scripts from abcde to ripit.

Has anyone else tried this? Do you see any reason that it won't work?

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#8 Post by julian67 »

Why would you want a ripper/encoder to run as a daemon or be started and stopped with an init script?

curly
Posts: 8
Joined: 2009-04-06 19:28

#9 Post by curly »

julian67 wrote:Why would you want a ripper/encoder to run as a daemon or be started and stopped with an init script?
The box is headless, i.e. no keyboard, mouse, nor monitor. I come back from the music store with a pile of cd's and push the button on the cd drive, pop in the first cd and it rips the cd. Then it ejects and waits for another cd. If no other cd it just waits and waits. It's an automatic ripping machine in addition to the other great things it does; like mpd.

The idea is sort of like several music 'server' type apparati available such as the Macintosh MS750, Escient fireball's, Bose, etc.

It's working great with abcde... finally.

I found your post while trying to glean some knowledge from the sparse info on abcde.

I really like your strategy and it looks like 'ripit' might be getting alot more developer attention than abcde at the moment. I can't quite figure out how to record the 'toc' with abcde, either, but that may be quite simple for greater minds than mine. The single file flac rip-embedded cue w/ abcde is ok as an archive but doesn't allow playback in the normal sense, as you state above.

Terabyte drives are getting pretty cheap these days but I'd rather not squander that space with unnecessary files.

Some things really cool about abcde;
  • comes with examples for daemon, init script, autorip, etc,
  • suports many more formats than ripit (although could be easily incorporated into ripit)
I've just installed ripit 3.7 beta and playing around with it with high hopes.

I hope I haven't said too much about nothing nor too little about something.

I'm running Debian lenny (stable), btw.

Cheers,
curly

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#10 Post by julian67 »

The abcde daemon and init scripts are really simple. There's no PID so it really is just a start command and a kill command in the init script, and the daemon just sets up a loop so no interactivity is required. In ripit a non-interactive loop is set in ~/.ripit/config with

eject=1
loop=1
interaction=0
verbose=0

and maybe:

submission=0

(I didn't check how cddb submissions might work with zero interaction).

There's no need to create a daemon as far as I can tell, unless there's some issue with typing 'ripit' once. You could make a ripit start up script in ~ and an init script which calls it as your user on boot but it seems like a waste of effort to me. I mean you have to physically present at the machine to feed the CDs so this isn't a process which must be able to be run 100% remotely so you might as well type 'ripit' as well, via ssh I guess. You could leave it running permanently and it will poll the drive every 12 seconds. Maybe use a screen session so it's out of the way.

abcded seems to be set up to run as root..doesn't seem a great idea to me.

jalu
Posts: 1389
Joined: 2008-11-19 23:26

#11 Post by jalu »

julian67 wrote:
abcded seems to be set up to run as root..doesn't seem a great idea to me.
i read that somewhere, but as i allways forget to become root: it also works fine as a user for me.

btw: i followed the how-to again (on my second drive): same result and same comment like my first experience. all went very good. thanks again, its a big help for setting it up.

greetings

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#12 Post by julian67 »

jalu wrote:julian67 wrote:
abcded seems to be set up to run as root..doesn't seem a great idea to me.
i read that somewhere, but as i allways forget to become root: it also works fine as a user for me.

btw: i followed the how-to again (on my second drive): same result and same comment like my first experience. all went very good. thanks again, its a big help for setting it up.

greetings
Good to hear it worked more than once. Perfection! :D

I meant the abcded daemon runs as root, not when the regular user runs abcde from the terminal.

jalu
Posts: 1389
Joined: 2008-11-19 23:26

#13 Post by jalu »

I meant the abcded daemon runs as root, not when the regular user runs abcde from the terminal.
ok, i misunderstood, sorry. i understood the text i've read that way, so i was kinda confused why it worked properly as user. now i got it, thanks. it`s still a long path to go :-)

greetings

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#14 Post by julian67 »

julian67 wrote:................... You could leave it running permanently and it will poll the drive every 12 seconds. Maybe use a screen session so it's out of the way.
I tried this this morning and forgot to kill the process. This evening I loaded a DVD and it was immediately ejected. Odd. Tried again...same thing...So I put an audio CD in the drive, closed the tray and ripit started ripping it in the background...no interaction. It definitely works :D

This is on a desktop running hal and dbus but as ripit doesn't use these it should behave the same way on a command line system.

curly
Posts: 8
Joined: 2009-04-06 19:28

#15 Post by curly »

julian67 wrote:..........It definitely works :D
Fantastic! Actually I couldn't see any reason why it wouldn't since ripit is very similar to abcde. But I'm no programmer so thanks for the experiment.
julian67 wrote:I meant the abcded daemon runs as root, not when the regular user runs abcde from the terminal.
\

Yeah. This was something bothering me. All the rips, folders, files are owned by root so there's an extra step to chmod/chown. I unashamedly use foobar2000 on windoW$ XP to tag and organize (lately). It's really the best and easiest for me to use that I've found anywhere. So when I check the tags or rename files folders, I need write permissions. I will still have to be vigilant with the tags since freecddb can be a real mess sometimes. Foobar2000 is about the only reason I keep a windows machine around.

So you set it up like you described? An init script to run as your user? That would be ideal, I think.

I guess my next step is to figure out whether I can have a DVD-combo drive for dynamic playing in addition to the dedicated CD-ripit drive used by the daemon.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#16 Post by julian67 »

curly wrote:
julian67 wrote:..........It definitely works :D
Fantastic! Actually I couldn't see any reason why it wouldn't since ripit is very similar to abcde. But I'm no programmer so thanks for the experiment.
julian67 wrote:I meant the abcded daemon runs as root, not when the regular user runs abcde from the terminal.
\

Yeah. This was something bothering me. All the rips, folders, files are owned by root so there's an extra step to chmod/chown. I unashamedly use foobar2000 on windoW$ XP to tag and organize (lately). It's really the best and easiest for me to use that I've found anywhere. So when I check the tags or rename files folders, I need write permissions. I will still have to be vigilant with the tags since freecddb can be a real mess sometimes. Foobar2000 is about the only reason I keep a windows machine around.

So you set it up like you described? An init script to run as your user? That would be ideal, I think.

I guess my next step is to figure out whether I can have a DVD-combo drive for dynamic playing in addition to the dedicated CD-ripit drive used by the daemon.
You define the drive in ripit's config so it should be easy enough to have it use one and ignore the other.

I didn't bother with an init script. I started ripit with

Code: Select all

$ ripit & disown
....and then forgot about it.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#17 Post by julian67 »

If you just want ripit to start up in the background on boot as your regular user you can make /etc/init.d/ripit

Code: Select all

#! /bin/sh
start-stop-daemon -c julian --start -b --exec /usr/bin/ripit
exit

Replace my username with yours and make the script executable and update-rc.d.

It's crude and there's no pid file or clean stop so you can inadvertently start several ripits by mistake but the start-stop-daemon is good for backgrounding a process that would normally produce some output.

Initially I followed the example /etc/init.d/skeleton but ripit doesn't produce a pid file and making one with start-stop-daemon didn't help, so I had no quick and easy way to have the init script quit on finding a running instance, or stop a running instance. So laziness and incompetence triumphed and compelled me to do it the easy crude way :D

curly
Posts: 8
Joined: 2009-04-06 19:28

#18 Post by curly »

How bout this? I just replaced "abcde" with "ripit" in the abcde.init script. I think there may be something missing, but I haven't tried it yet.

(edit:) I realize it's missing the directive to run as a specified user but I'm not quite sure where to put that. I'll see if I can figure it out.

Code: Select all

#!/bin/sh

##########
# The first argument tells what to do.
##########

RUNNING=`ps -ef|grep [r]ipit|awk '{ print $2 }'`

state=$1

case $state in
start)

        if [ -n "$RUNNING"  ]; then
                echo "ripit daemon already running."
                exit 0
        fi

        echo "Starting ripit daemon"
        ripit &
        echo "Done."
        ;;
stop)
        if [ -n "$RUNNING"  ]; then
           /bin/kill -9 $RUNNING > /dev/null
           if [ $? = 0 ]; then
                echo "ripit daemon killed"
           fi
        fi
        ;;
restart)
        $0 stop
        $0 start
        ;;
*)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac
And here's the abcded daemon script which may be unnecessary - I haven't tried to modify this yet but just as an example. The abcded script included in the abcde examples would not work properly for me. I found this version at some Finnish guy's DVR blog but I modified it slightly to just use the /etc/abcde.conf file.

Code: Select all

#!/bin/sh
DATE=`date +%Y-%m-%d_%Hh%Mm%S`
DELAY=10
CDPARANOIA=â€

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#19 Post by julian67 »

I can only suggest trying it out.

To have a scripted command run as a different user in bash you can use

Code: Select all

su -c 'command' $USER
and as it's an init script it's running as root and no password is needed.

You just need to define USER with the other variables at the beginning of the script, i.e.

USER='curly'

If you use the start-stop-daemon it's a -c $USER to run as a different user

I'm actually happy to do it my crude and bad way because I have a headless machine with a DVD/CD drive which I'd not even thought about for ripping until you mentioned the idea of a completely automated ripping box (thanks btw!) and I never use the optical drive for anything. It's a slimline slotloader and won't fit in anything else I have, and the machine runs Debian stable and only gets rebooted for kernel updates...that is pretty rare. So I don't need to be able to stop or restart ripit, it can just run in the background forever. But I think it's very neat that I just push a CD in and a few minutes later it spits it out and I didn't have to do anything, not even push a tray shut or press a button :D

curly
Posts: 8
Joined: 2009-04-06 19:28

#20 Post by curly »

julian67 wrote:.. the idea of a completely automated ripping box (thanks btw!)
Well, thank YOU! I'm glad you found it useful. I was actually starting to wonder if I was crazy or not...
julian67 wrote:...and I didn't have to do anything, not even push a tray shut or press a button :D
Ain't it just da bomb?!?!

As a sort of side note, I did find a patch for abcde to get a TOC, http://www.mail-archive.com/debian-bugs ... 13298.html in case anyone wants that.

I'm looking forward to trying ripit, though.

It will probably be a few days before I have time to trial and error this since I still have to learn ripit first, as well. I'll post back my working config (fingers crossed).

Post Reply