PDA

View Full Version : abcde usage (with flac)



Bill Moseley
2005-03-16, 20:08
Debian Sid & SB1 owner. Yet another "best way to rip" question.

I normally use grip to rip to ogg. But listening to people here makes
me think I should go out and get a few honkin' drives, a dvd burner,
and rip to flac. I already have a number of title ripped to flac, but
mostly ogg and some mp3.

I have a few flac questions, and then also looking for tips on using
abcde.

And, yes, I did see Michael Peters scripts today. Looks like more
work -- and I don't mind the cddb errors. But I should look at them
again.

About flac -- I thought I saw a post where someone was suggesting
ripping CDs as a *single* flac. Is there a reason to do this? If so,
how are the songs managed individually? Can Slimserver play
individual songs in this case?

I also see talk of using cue/toc sheets. Will slimserver use those
for indexing songs -- and can then the songs be played individually?

I also noticed with the flac files I've played on my SB1 that the
audio level seems low. Is --replay-gain something that could help?

Now, if you use abcde, could you give some tips on your usage? What do
you set in your ~/.abcde.conf file, and what command line parameters
do you use?

I tried this:

abcde -1 -a tag,playlist -o flac -R -w comment 1-3

hoping to get a single file with the first three songs, but it ripped
and encoded the entire cd.

$ ls -l
total 427860
-rw-r--r-- 1 moseley moseley 650 2005-03-16 17:34 cddbchoices
-rw-r--r-- 1 moseley moseley 148 2005-03-16 17:34 cddbquery
-rw-r--r-- 1 moseley moseley 1078 2005-03-16 17:34 cddbread.1
-rw-r--r-- 1 moseley moseley 986 2005-03-16 17:34 cddbread.2
-rw-r--r-- 1 moseley moseley 590 2005-03-16 17:34 cddbstat
-rw-r--r-- 1 moseley moseley 4 2005-03-16 17:34 cdparanoia-audio-tracks
-rw-r--r-- 1 moseley moseley 108 2005-03-16 17:34 discid
-rw-r--r-- 1 moseley moseley 318 2005-03-16 17:49 status
-rw-r--r-- 1 moseley moseley 438092326 2005-03-16 17:49 track01.flac

which doesn't seem to helpful. I guess I kind of want a single command to rip
and encode and store it in my music collection in some reasonable
order. I suppose artist/album/ makes sense (if I can determine the
one artist).


BTW -- also saw a post where they said EAC was better at ripping that
cdrdao/cdparanoia. Is that true? If so, why?



Thanks,



--
Bill Moseley
moseley (AT) hank (DOT) org

Michael Peters
2005-03-16, 21:07
On Wed, 16 Mar 2005 19:08:12 -0800, Bill Moseley <moseley (AT) hank (DOT) org> wrote:

>
> BTW -- also saw a post where they said EAC was better at ripping that
> cdrdao/cdparanoia. Is that true? If so, why?

It is true, though with most CD's there isn't a difference.
On damaged CD's, you are more likely to get an accurate rip with EAC
than with cdparanoia.
On damaged CD's, both will take a hell of a long time though, and not
guarantee an accurate rip.

--
http://mpeters.us/

Karel Tromp
2005-03-17, 01:52
On Wed, 16 Mar 2005 19:08:12 -0800, Bill Moseley <moseley (AT) hank (DOT) org> wrote:
>
> Now, if you use abcde, could you give some tips on your usage? What do
> you set in your ~/.abcde.conf file, and what command line parameters
> do you use?
There's a site named www.hydrogenaudio.com where they talk a lot about
ripping and the best way to do it. Under Linux they user mostly '
grip' or 'ripperx' . The first one I have tried and looks a lot like
CDex under Windows. I you van install the programs for flac and lame
you can rip-on-the-fly to mp3 or flac. It uses cdparanoia for ripping
but has a nice front-end for it.

>
> BTW -- also saw a post where they said EAC was better at ripping that
> cdrdao/cdparanoia. Is that true? If so, why?
>

Most of the cdreaders out there have a cache. I have read that for
proper ripping the cache needs to be disabled. On linux cdparanoia can
not disable the cache so a cacheless cdromdrive is being recommended
for ripping with cdparanoia. Ffor an exact rip sectors from a damaged
cd will be read repeatedly. When a cddrive is cached repeated reading
is of no use because the information would be read out of the cache
instead of the cd.

EAC can disable the cache but is a Windows-program.

With a no-cache cdromdrive there should be no difference in
quality-ripping between cdparanoia and EAC.

Karel

michael
2005-03-17, 02:39
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCOVBZJa41g0n42gMRAgjDAJsFSrpMi8KnwMRLo10HuS 4iC+OFbQCfeu9f
JWcDHrT7yg/svF0VXWFejY0=
=hYXR
-----END PGP SIGNATURE-----

Bill Moseley
2005-03-17, 07:49
On Thu, Mar 17, 2005 at 09:52:34AM +0100, Karel Tromp wrote:
> On Wed, 16 Mar 2005 19:08:12 -0800, Bill Moseley <moseley (AT) hank (DOT) org> wrote:
> >
> > Now, if you use abcde, could you give some tips on your usage? What do
> > you set in your ~/.abcde.conf file, and what command line parameters
> > do you use?
> There's a site named www.hydrogenaudio.com where they talk a lot about
> ripping and the best way to do it. Under Linux they user mostly '
> grip' or 'ripperx' . The first one I have tried and looks a lot like
> CDex under Windows. I you van install the programs for flac and lame
> you can rip-on-the-fly to mp3 or flac. It uses cdparanoia for ripping
> but has a nice front-end for it.

Ok, I'll check out that site. I guess I'm more interested in a
command line utility/script to replace grip and abcde looks
interesting. I thought it might be commonly used and someone here
could share their methods.

Actually, having Slimdevices rip to flac seems like not a bad deal.
First it seemed expensive, but ripping does take time.

> Most of the cdreaders out there have a cache. I have read that for
> proper ripping the cache needs to be disabled. On linux cdparanoia can
> not disable the cache so a cacheless cdromdrive is being recommended
> for ripping with cdparanoia. Ffor an exact rip sectors from a damaged
> cd will be read repeatedly. When a cddrive is cached repeated reading
> is of no use because the information would be read out of the cache
> instead of the cd.
>
> EAC can disable the cache but is a Windows-program.

That's interesting. Thanks for explaining that. It's odd, though,
as I don't really see any reason why cdparanoia couldn't also disable
the cache.

But maybe there's other issues, too:

http://www.hydrogenaudio.org/forums/index.php?act=ST&f=20&t=3164

I always assumed with cdparanoia enabled that you would not get exact
copies over multiple runs due to the error correction, and that was
the trade off for trying to read damaged source. I'm not clear
from the article if they are saying EAC is better because it
*reported* the errors and CDex didn't or because the actual ripping
was more accurate with EAC.


--
Bill Moseley
moseley (AT) hank (DOT) org

Bill Moseley
2005-03-17, 08:00
On Thu, Mar 17, 2005 at 01:39:30AM -0800, michael wrote:
> > I also see talk of using cue/toc sheets. Will slimserver use those
> > for indexing songs -- and can then the songs be played individually?
>
> Exactly.
>
> If you decide to go that route and want more details on external
> cuesheets vs. embedded cuesheets, or tagging styles for multi song
> flacs, just ask.

Ok, I'd like to know more.

One thing I've wanted to know how to do (on Linux) is take say a live
recording and create a toc/cuesheet to mark off songs. There's where
a gui would be nice -- be able to shuttle to a spot and set a mark
and the write those marks to a new toc (as I use cdrdao). It would
be nice to be able to do that with flac, I suppose.

> > I also noticed with the flac files I've played on my SB1 that the
> > audio level seems low. Is --replay-gain something that could help?
>
> Maybe.
> replay gain will be most useful for making all your files seem to have
> about the same volume relative to each other.

As long as everything is flac/ogg with --replay-gain set, right?
Some random mp3 in the playlist won't be effected by this.

I thought I saw a volume normalization plugin somewhere. Maybe I
just thought that would be nice as my player went from a quite song
at full volume to the next song that was, well, not quite at all.





--
Bill Moseley
moseley (AT) hank (DOT) org

Michael Peters
2005-03-17, 16:25
On Thu, 17 Mar 2005 10:41:26 -0500, Michael Haan
<michael_haan (AT) hotmail (DOT) com> wrote:
>
>
>
> I just started using abcde to rip to flac last night. It seemed a little
> slow, but given everything that was going on on the box, and the processes
> nice level, I wasn't surprised. Anyway, I haven't yet figured out exactly
> how to configure abcde the way I want just yet. On the single file per cd
> issue, I'm with you. I have my entire collection in flac and would never
> even thing of ripping cds to a single file with cue sheets - seems
> unnatural.

If things were better integrated it wouldn't seem un-natural - they
would appear as individual songs in your music player etc.

Some of the jukeboxes for Windows do this, once ripped - there's no
need to think of it as a single file.

I just personally never saw the point of ripping as a single file and
using a cue sheet.

--
http://mpeters.us/

michael
2005-03-17, 18:23
Michael Peters <funkyres (AT) gmail (DOT) com> writes:
....
> If things were better integrated it wouldn't seem un-natural - they
> would appear as individual songs in your music player etc.
>
> Some of the jukeboxes for Windows do this, once ripped - there's no
> need to think of it as a single file.

Yeah, it would be nice if this was supported by more systems. To my
knowledge, at the moment it just slimserver, or if you're a windows
user, foobar2000. There's a plugin for xmms, but it's some what
closer to clunky than seemless.

-michael

michael
2005-03-17, 18:58
Bill Moseley <moseley (AT) hank (DOT) org> writes:
> On Thu, Mar 17, 2005 at 01:39:30AM -0800, michael wrote:
....
>> If you decide to go that route and want more details on external
>> cuesheets vs. embedded cuesheets, or tagging styles for multi song
>> flacs, just ask.
>
> Ok, I'd like to know more.

Anything in particular you'd like to know?

The only big caveat right now (as far as slim server goes anyway) is
that for a particular file you'll want to use either external OR
embedded cuesheets/metadata. Trying to use both for the same file will
often leave you with strange listings in slimserver. Past that, it's
a matter of choice which you use. I use embedded cuesheets because I
find it convenient to keep everything in one file. Other folks prefer
external cuesheets because it's what their ripper spits out
(particularly EAC).

> One thing I've wanted to know how to do (on Linux) is take say a live
> recording and create a toc/cuesheet to mark off songs. There's where
> a gui would be nice -- be able to shuttle to a spot and set a mark
> and the write those marks to a new toc (as I use cdrdao). It would
> be nice to be able to do that with flac, I suppose.

I don't know of any gui cue/toc editors off the top of my head. It's
pretty rare that I have to craft one from scratch though, so I haven't
really looked that hard. The main data point in a cuesheet is just a
timestamp, so they're actually pretty easy to deal with by hand in any
text editor. A nice gui audio editor is quite handy for determining
those timestamps with any precision though. And if you're working
with live recordings, remember that the pre-gap is your friend.
(One of my personal goals is for slimserver to eventually treat these
the same way a cd player would.)

Also, if you haven't already stumbled across it, cuetools is
invaluable for converting between toc and cuesheet.
You may also find shntool handy for easily splitting multi-song
archives into separate files if you ever have the need, or gluing them
back together again.

>> > I also noticed with the flac files I've played on my SB1 that the
>> > audio level seems low. Is --replay-gain something that could help?
>>
>> Maybe.
>> replay gain will be most useful for making all your files seem to have
>> about the same volume relative to each other.
>
> As long as everything is flac/ogg with --replay-gain set, right?
> Some random mp3 in the playlist won't be effected by this.

It is on a per-file basis. There are programs that will do similar
things to an mp3. mp3gain is the one I use under linux. The difference
lies in the way it's applied. mp3gain will make the change to the
mp3file, and it will play with it's new loudness on any
mp3player. (yes, it is reverseable.) For FLAC, you'll just get tags
written to the file, and it's the decoders responsibility to apply the
change. Hopefully this will all be transparent with slimserver, but
you might notice the difference on other players.

> I thought I saw a volume normalization plugin somewhere.

I'm not aware of one, but there might be something like that floating
around. One more point while we're on the topic, many programs that
offer "normalization" are performing a totally different calculation
than what replaygain uses. Not only is replaygain a better method,
but mixing and matching replaygain and "normalization" will leave you
with different apparent loudness on different files, which kind of
defeats the whole point.

> Maybe I
> just thought that would be nice as my player went from a quite song
> at full volume to the next song that was, well, not quite at all.

That can be quite annoying. I'm quickly becoming a big fan of
replaygain for just that reason.

-michael

--
"I must create my own system, or be enslav'd by another man's"
-William Blake

michael
2005-03-17, 19:00
Bill Moseley <moseley (AT) hank (DOT) org> writes:
> On Thu, Mar 17, 2005 at 01:39:30AM -0800, michael wrote:
....
>> If you decide to go that route and want more details on external
>> cuesheets vs. embedded cuesheets, or tagging styles for multi song
>> flacs, just ask.
>
> Ok, I'd like to know more.

Anything in particular you'd like to know?

The only big caveat right now (as far as slim server goes anyway) is
that for a particular file you'll want to use either external OR
embedded cuesheets/metadata. Trying to use both for the same file will
often leave you with strange listings in slimserver. Past that, it's
a matter of choice which you use. I use embedded cuesheets because I
find it convenient to keep everything in one file. Other folks prefer
external cuesheets because it's what their ripper spits out
(particularly EAC).

> One thing I've wanted to know how to do (on Linux) is take say a live
> recording and create a toc/cuesheet to mark off songs. There's where
> a gui would be nice -- be able to shuttle to a spot and set a mark
> and the write those marks to a new toc (as I use cdrdao). It would
> be nice to be able to do that with flac, I suppose.

I don't know of any gui cue/toc editors off the top of my head. It's
pretty rare that I have to craft one from scratch though, so I haven't
really looked that hard. The main data point in a cuesheet is just a
timestamp, so they're actually pretty easy to deal with by hand in any
text editor. A nice gui audio editor is quite handy for determining
those timestamps with any precision though. And if you're working
with live recordings, remember that the pre-gap is your friend.
(One of my personal goals is for slimserver to eventually treat these
the same way a cd player would.)

Also, if you haven't already stumbled across it, cuetools is
invaluable for converting between toc and cuesheet.
You may also find shntool handy for easily splitting multi-song
archives into separate files if you ever have the need, or gluing them
back together again.

>> > I also noticed with the flac files I've played on my SB1 that the
>> > audio level seems low. Is --replay-gain something that could help?
>>
>> Maybe.
>> replay gain will be most useful for making all your files seem to have
>> about the same volume relative to each other.
>
> As long as everything is flac/ogg with --replay-gain set, right?
> Some random mp3 in the playlist won't be effected by this.

It is on a per-file basis. There are programs that will do similar
things to an mp3. mp3gain is the one I use under linux. The difference
lies in the way it's applied. mp3gain will make the change to the
mp3file, and it will play with it's new loudness on any
mp3player. (yes, it is reverseable.) For FLAC, you'll just get tags
written to the file, and it's the decoders responsibility to apply the
change. Hopefully this will all be transparent with slimserver, but
you might notice the difference on other players.

> I thought I saw a volume normalization plugin somewhere.

I'm not aware of one, but there might be something like that floating
around. One more point while we're on the topic, many programs that
offer "normalization" are performing a totally different calculation
than what replaygain uses. Not only is replaygain a better method,
but mixing and matching replaygain and "normalization" will leave you
with different apparent loudness on different files, which kind of
defeats the whole point.

> Maybe I
> just thought that would be nice as my player went from a quite song
> at full volume to the next song that was, well, not quite at all.

That can be quite annoying. I'm quickly becoming a big fan of
replaygain for just that reason.

-michael

--
"I must create my own system, or be enslav'd by another man's"
-William Blake

Jason Voegele
2005-03-19, 07:13
On Thursday 17 March 2005 10:00 am, Bill Moseley wrote:
> On Thu, Mar 17, 2005 at 01:39:30AM -0800, michael wrote:
> > If you decide to go that route and want more details on external
> > cuesheets vs. embedded cuesheets, or tagging styles for multi song
> > flacs, just ask.
>
> Ok, I'd like to know more.
>
> One thing I've wanted to know how to do (on Linux) is take say a live
> recording and create a toc/cuesheet to mark off songs. There's where
> a gui would be nice -- be able to shuttle to a spot and set a mark
> and the write those marks to a new toc (as I use cdrdao). It would
> be nice to be able to do that with flac, I suppose.

Here's the process I've been using (scripted, of course):

1) Rip the entire CD to a single WAV file:
cdparanoia "[::]-" CD.wav
2) Read the CD's TOC:
cdrdao read-toc --fast-toc --datafile CD.wav CD.toc
3) Convert TOC to CUE:
cueconvert -f CD.toc -f CD.cue
4) Get CDDB information and store it in a YAML file

That is the ripping process. It gets all of the information that is derived
from the source CD, so that the next step, encoding, can be done separately.
I encode to several different formats for various purposes:

1) Encode single WAV file to single FLAC file:
flac --cuesheet=CD.cue [insert tags here...] CD.wav
2) Split CD.wav into multiple WAV files:
cuebreakpoints -f CD.cue | shnsplit CD.wav
3) Now that I have individual WAV files per track, I encode them to Ogg Vorbis
and mp3.

The cuetools package and the shntool package are not available in Debian, but
you can get them from the RareWares repository:

deb http://www.rarewares.org/debian/packages/unstable ./

Some of the problems that I've yet to resolve are:

* Some CUE sheets that list DATA segments cannot be added to the FLAC CUESHEET
block. I may need to massage some CUE sheets before encoding the FLAC file,
so that I can remove such DATA segments.
* How to tag multi-disc sets. Slim provides support for a DISC tag, but I
think I need two tags: DISCNUMBER and DISCNAME (for multi-disc sets where
each disc has its own title)

Let me know if you have any other questions. I've been pretty heavily
researching how to do all this on Debian for quite a while. Pretty soon I'll
have a Ruby script that others might be able to use, but right now it's
pretty specific to my environment.

--
Jason Voegele

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCPDORHe0AH0X+WAIRAjF3AJ9wxyB6/xcTxTbA7IE5iAhSh+WbJgCgsTaG
JWdsouc0NO4aYxnLh3EeWmo=
=OA83
-----END PGP SIGNATURE-----