Hello William,

thanks for the reply

On Tue, 2006-06-06 at 14:58 -0400, William Ferrell wrote:

> 
> What kind of slowness do you experience with it? I've actually been
> pleased with its performance; it essentially just deinterleaves the CD
> +G and audio data, writes them to separate files, does a FreeDB
> lookup, and invokes lame or oggenc to encode the audio. 
> 

I haven't done much testing but I did an initial test to compare dcdgrip
to cdgrip (with a oggenc instead of lame)
cdgrip too just over 10mins 47secs (user)
dcdgrip took 7mins 2ses (user)

> 
> Excellent :) It's always a good feeling when you get that first
> successful run from a new tool :) 

Yes it is :D I'm doing it err Just for fun (TM), I'm not really much of
a programmer as you'll see when you look at the code :)

> Which parts are faster? Have you done any profiling to see which parts
> are (apparently much) faster in the C version? It'd be interesting to
> know where the bottlenecks are in cdgrip. 

I haven't done that. I've never used gprof but I intend to like
everything else.


> Oooh, now this is cool. Has it been accurate so far in getting tracks
> split correctly?

Yes. 

A little detail:

It decodes the q channel and checks to see if the track number has
changed.

If it has the program then does a CRC check (there is a CRC value built
into the q channel) and if the CRC is bad the change of track is
ignored. Initially I didn't include the CRC checking but I found that
the q data was often corrupted in one or two sectors in the track so the
CRC eliminates these erroneous track boundaries. 

This introduces a problem; what if the q channel corruption happens at a
track boundary?

Well the answer is you miss it by one sector (ie 1/75 of a second) which
I can live with.

Extra checking could be introduced to help with this problem because
often the track number is correct even if the CRC fails (because some
other part of the q channel is wrong by one bit) If the program checked
to see if the change in track number persisted over a number of sectors
and if it did used the sector with the bad CRC anyway then the chances
of missing a track boundary would be next to zero. I haven't done this
yet because it seems like a rare error and who cares about 1/75 of a
second anyway? (there could be problems with cdg data but I doubt anyone
every puts any cdg packets that close to a track boundary)

> 
> If this works well, it'd be useful to me since I'm looking for a way
> to rip/encode just *one* track on a disc, and not the whole disc
> (Linux is still missing a
> play-CDG-tracks-straight-from-a-real-CDG-disc program as far as I
> know, and this would be a close substitute until such a tool exists
> (or I shut up and write one :P)) 
> 
> It occurs to me if I run an all-digital karaoke show with this suite
> and the stuff I've written up to now, I'm boned if someone walks up
> when I call their name, hands me a disc, and says "track 12." As it
> stands right now I'd have to rip the whole CD and convert it all (I
> could "neuter" cdgrip and have it skip the encode step, just writing
> to WAV, which pykaraoke will play, but we're still talking about at
> least six minutes to rip and split the data). 

dcdgrip doesn't do this yet but... as such. If I'm understanding you
correctly you want to read one track and then split and encode it.

I have already thought of adding an option to select which tracks you
want to rip (from the complete bin file) but it shouldn't be too hard to
make it encode from a bin file containing just one track (will cdrdao do
this?)


> 
> 
> 
>         * It combines the ripping and deinterleaving and also performs
>         a CRC on
>         the q code block in to one step (this might give some speed
>         benifits)
> 
> Interesting; I suspect this does speed things up a bit. 

I think what I wrote here was a bit misleading ( infact I'm not even
sure I know what I meant to write :) dcdgrip doesn't actually read CDs
(although I've been looking into it) it works with bin files just like
cdgrip.

What dcdgrip does differently it reads the bin file, splits the audio
and cdg, deinterleaves the cdg and writes it to a file and pipes the
audio to the encoder all in one go, sector at a time (well it needs
three sectors really, but that's just splitting hairs)

Cdgrip does all these steps separately. It writes to disk and the points
the encoder at it etc. 

Also cdgrip builds very large arrays for instance in bin2pcm function a
whole tracks worth of audio gets put into a single array.  I'm not
saying this is a bad thing, it works fine on my system but dcdgrip never
gets close to using this much memory and as a consequence might work
better where memory is limited.


>         
>         * I can't make it work with LAME and I've not idea why :)
> 
> What happens when you try?
> 

This is the thing that I find most frustrating and I would really like
it if someone explained to me.

I use a pipe to send data to oggenc. The code looks like this:

encoder_stream = popen(enc_string, "w")

this works fine.

However if I substitute lame for oggenc (and no matter what options I
pass) lame generates a SIGPIPE and dies. It just does not want to encode
from a pipe, which is odd because I'm sure you can pipe to lame on the
command line.


> 
> Yeah, drives are very random and finicky about this part of things.
> Figuring out whether you've been handed raw or cooked subchannel data
> is a pain in the [EMAIL PROTECTED] :) 


I'm not totally convinced that it's just a drive problem. Has anyone on
the list every got RW data to work?

> Sure :) Toss it up to the list if you'd like or send it privately; I
> wouldn't mind seeing it. 

I'll send it to the list. I'm just having a small tidy up and will post
it immediately after (you can laugh heartily at my code :)

Drew





_______________________________________________
Pykaraoke-discuss mailing list
Pykaraoke-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss

Reply via email to