Hi all,
I posted a few months ago with a plan about building a karaoke system
using pykaraoke. One thing I noticed was that cdgrip was a little slow
to rip and I wondered if I could make any improvements.
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 wrote some code in C and got to the stage of having it ripping to ogg
using oggenc as the encoder.
Excellent :) It's always a good feeling when you get that first successful run from a new tool :)
There are some differences between my code and and cdgrip (apart from
the language of choice)
* It is a little bit faster (maybe 20%) probably mostly as a result of
being compiled.
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.
* It works on the bin file by analysing the q subcahnnel so never needs
to look at the TOC file
Oooh, now this is cool. Has it been accurate so far in getting tracks split correctly?
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).
* Because of the above it will probably work with cue/bin files although
I don't have a way to test this at the moment.
Have a quick look at bchunk if you get a chance; it works with the ISO and cue/bin formats and this will probably tell you whether your tool will easily adapt to the formats.
* 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.
What's wrong with it?
* It's in C
This is not a fault, but a choice :)
* It's unfinished and doesn't do CDDB lookups yet
* I can't make it work with LAME and I've not idea why :)
What happens when you try?
Some other notes.
While I was writing it (I call it dcdgrip) I tried to write a
NoDeinterleave option like cdgrip has. It didn't work properly, and I
think the same option in cdgrip might also be broken (mostly because I
just copied the code and translated it into C).
I think that maybe the deiterleaved data returned by cdrdao doesn't look
the way the code expects. Or the drives I've made work with the rw
option are returning something odd. It's hard to track down the source
of these errors.
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] :)
Anyway...
Is anyone interested in the code?
Sure :) Toss it up to the list if you'd like or send it privately; I wouldn't mind seeing it.
I got to the current stage over a month ago but have been too busy to
work on it since. I've got a bit more free time now.
I'll post it or upload somewhere or whatever if anyone is interested.
Also I'd say it was GPL but I took some public domain code for a CRC
algorithm and I'm not sure how that works with the GLP (in any case the
CRC stuff could be rewritten if needed)
Public domain sounds "GPL-compatible" to me, but IANRMS so take that advice with a grain of salt :)
--
Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family!
_______________________________________________ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
