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
