Re: [Pykaraoke-discuss] New ripper
> Well, I haven't actually gotten a drive yet, but shortly. > > Unless you meant for me to do it on the Toshiba internal... When you get a new drive - it would be good to get some examples from another device. Out of interest have you tried cdrdao on the Toshiba's drive? Probably won't do RW if it doesn't work with CDRWIN but may be worth a shot if you have the time. Kelvin. Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
On Tue, Jun 27, 2006 at 12:23:34AM +0100, Kelvin Lawson wrote: > > Could some testing software be whipped up? I wouldn't object to > > spending the money on some specific CD+G disc (so that we all have the > > same baseline) if there was something I could run against that disc to > > diagnose what the drive was shipping over... > > Cheers Jay. I don't think we'll need to all rip the same disc now, > judging by what Drew sent out tonight. If you have time, it would be > good if you could pick any disc and do a rip in both RW and RW_RAW mode, > and send along the first 100KB or so of each rip. Well, I haven't actually gotten a drive yet, but shortly. Unless you meant for me to do it on the Toshiba internal... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail? Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
> Could some testing software be whipped up? I wouldn't object to > spending the money on some specific CD+G disc (so that we all have the > same baseline) if there was something I could run against that disc to > diagnose what the drive was shipping over... Cheers Jay. I don't think we'll need to all rip the same disc now, judging by what Drew sent out tonight. If you have time, it would be good if you could pick any disc and do a rip in both RW and RW_RAW mode, and send along the first 100KB or so of each rip. Kelvin. Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
On Mon, Jun 26, 2006 at 12:46:59AM +0100, Kelvin Lawson wrote: > From reading about other people who have tackled the > software-deinterleave process (e.g. the Audiograbber guy) my > understanding was that this was a pain-in-the-ass that you can avoid by > using RW drives. I'd be surprised if there was anything particularly > complicated to do so we must be missing something simple. You said you > looked at the bin file - did you compare it with the RW_RAW output from > the same disk? If you have an example of the first few KB output using > both modes I'd be interested to see it. Could some testing software be whipped up? I wouldn't object to spending the money on some specific CD+G disc (so that we all have the same baseline) if there was something I could run against that disc to diagnose what the drive was shipping over... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail? Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
> Yes, absolutely. I would like to know if anyone else has successfully > compiled and test it. Great, I can feel a v0.4 coming on. We're in the middle of buying a house at the moment so time is limited, but I'll have a go at building it here and fitting it into a sensible release package. > When I had extracted the .bin image I ran it through dcdgrip to split it > but the results were not as expected. The CDG info was garbage and the > audio was very badly distorted (like samples were missing and maybe cdg > data was still present) Interesting. I certainly didn't expect the audio to be affected by using RW mode. I'm inclined to go with your reason 3 as well - that the data is not arriving in the expected order. Could the CDG data be smaller because the parity bytes have been removed? From reading about other people who have tackled the software-deinterleave process (e.g. the Audiograbber guy) my understanding was that this was a pain-in-the-ass that you can avoid by using RW drives. I'd be surprised if there was anything particularly complicated to do so we must be missing something simple. You said you looked at the bin file - did you compare it with the RW_RAW output from the same disk? If you have an example of the first few KB output using both modes I'd be interested to see it. Cheers, Kelvin. Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
On Sun, Jun 25, 2006 at 02:27:11PM -0400, William Ferrell wrote: > Ah. Well, ogg is fine with me, as long as the player will track it. > FreeDB is a bit more important -- you'd be surprised how many karaoke > CDGs are actually in there. > >I feel the need to chime in here and say Ogg Vorbis is *very* important >here, especially when ripping a bigger collection. There's logistic, >performance, and legal reasons why Ogg Vorbis is the appropriate format for >compressed audio at a karaoke show. Indeed. >1) Same sound quality (or better) -- Ogg Vorbis does a great job >compressing music; of course this is subjective but Oggs always >sound either indistiguishable from the same music compressed by MP3 >or perceptively better. That's good to, um, hear. :-) >2) Better compression ratios -- Oggs end up smaller than MP3s for the >"equivalent" compression settings; i.e. if it sounds the same as an MP3, >it'll be smaller as an Ogg, and if an Ogg the same size as an equivalent >MP3, it will have fewer artifacts and generally sound better. Important when you're squishing 400 discs... >3) Faster compression/decompression -- On my 64-bit (AMD Athlon 64) >notebook, Ogg encoding can sometimes run almost twice as fast as equivalent >MP3 encoding. It's such a huge performance improvement that when I put a >pile of Oggs together to re-convert back to MP3 to burn to a CD my truck's >MP3-capable (but not Ogg-capable, dammit) player can grok, I'm disappointed >that it takes more time to actually convert the files than it does to write >the physical disc. Hee. I hadn't realized this was true, and I'm quite happy to hear it. >4) Royalty/patent free -- I know it's mostly an "academic" issue >since MP3's patent holders haven't apparently been complete >bastards about it, I don't have to worry at all that some lawyer >or cop will walk in during one of my shows and shut me down for >not paying a licensing fee to use a patented audio decoder. Same >with releasing software that uses it; my understanding is that the >MP3 folks *do* raise an eyebrow occasionally on players if those >players generate revenue for their builders/authors. Hmmm... >I haven't made empirical comparisons for the rest of this but I suspect >Ogg's tags can hold more data (they can be longer than ID3 tags), I know >players seem better-behaved (xmms is definitely faster/more cooperative >playing Oggs than it is playing MP3s, at least on both my systems), etc. Is it really? You mean, like, skipping and stuff? >And let me tell you this: on a song collection exceeding 40,000 songs, >pushing 150GB, converting from MP3 (I kept the originals, don't panic) to >Ogg Vorbis dropped the collection down to 110GB and sounds just as good. Yum. But note, too, that they pointout you're better off (much better, I'm told) re-ripping the originals to Ogg than converting. > > > Has anyone looked into cdparanoia? > > > > I couldn't find an option for ripping with subcode but I didn't look > > that closely. > Amusingly, googling for cdparanoia subcode turns up... > me and Will, talking about whether it will do it or not. :-) > >That's hilarious. I'd really love to find a way to either play CDG >straight from a CD or be able to rip just one track (during a show, >it'll be a pain in the ass if someone brings their own disc to play >but doesn't hand it to me until it's their turn to sing ... "yeah, >it'll be about ten minutes before you can sing this because my >computer has to read the whole disc first") Well, it's often about 10 minutes anyway, isn't it? Most of our ringers hand in the disc *as* their request slip, round here. And you should always have a "real" player and at least a couple dozen assorted discs as a backup anyway, so... Yeah, I know; I'm one of those old-fashioned "has a mixer" guys... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail? Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://l
Re: [Pykaraoke-discuss] New ripper
On 6/25/06, Jay R. Ashworth <[EMAIL PROTECTED]> wrote: On Sun, Jun 25, 2006 at 06:46:05PM +0100, Drew wrote:> > Well, having finally gotten SuSE 10.0 onto my laptop and the 100GB> > drive (which freed up the 80GB to go in the external chassis), I'm> > about to start ripping my 400 disc library -- which includes a lot of > > brands, though only a couple Sound Choice and Music Maestro discs -- so> > I guess I can A/B compare them, and see what I get. Even a 10% speedup> > is worth it on 400 discs. :-)> > I'm pretty sure you'll see a speed increase. As far as ripping all 400> disks my code is missing some important features that cdgrip.py has. The> main ones are the track name lookups and the ability to use lame instead > of oggenc.Ah. Well, ogg is fine with me, as long as the player will track it.FreeDB is a bit more important -- you'd be surprised how many karaokeCDGs are actually in there. I feel the need to chime in here and say Ogg Vorbis is *very* important here, especially when ripping a bigger collection. There's logistic, performance, and legal reasons why Ogg Vorbis is the appropriate format for compressed audio at a karaoke show. Some of this is anecdotal for me, since I've done it myself and have seen these benefits, but I haven't actually done a "laboratory-style" suite of tests to prove these things. Though some of it is pretty damned easy to demonstrate anyway. 1) Same sound quality (or better) -- Ogg Vorbis does a great job compressing music; of course this is subjective but Oggs always sound either indistiguishable from the same music compressed by MP3 or perceptively better. 2) Better compression ratios -- Oggs end up smaller than MP3s for the "equivalent" compression settings; i.e. if it sounds the same as an MP3, it'll be smaller as an Ogg, and if an Ogg the same size as an equivalent MP3, it will have fewer artifacts and generally sound better. 3) Faster compression/decompression -- On my 64-bit (AMD Athlon 64) notebook, Ogg encoding can sometimes run almost twice as fast as equivalent MP3 encoding. It's such a huge performance improvement that when I put a pile of Oggs together to re-convert back to MP3 to burn to a CD my truck's MP3-capable (but not Ogg-capable, dammit) player can grok, I'm disappointed that it takes more time to actually convert the files than it does to write the physical disc. 4) Royalty/patent free -- I know it's mostly an "academic" issue since MP3's patent holders haven't apparently been complete bastards about it, I don't have to worry at all that some lawyer or cop will walk in during one of my shows and shut me down for not paying a licensing fee to use a patented audio decoder. Same with releasing software that uses it; my understanding is that the MP3 folks *do* raise an eyebrow occasionally on players if those players generate revenue for their builders/authors. I haven't made empirical comparisons for the rest of this but I suspect Ogg's tags can hold more data (they can be longer than ID3 tags), I know players seem better-behaved (xmms is definitely faster/more cooperative playing Oggs than it is playing MP3s, at least on both my systems), etc. And let me tell you this: on a song collection exceeding 40,000 songs, pushing 150GB, converting from MP3 (I kept the originals, don't panic) to Ogg Vorbis dropped the collection down to 110GB and sounds just as good. > > Has anyone looked into cdparanoia?>> I couldn't find an option for ripping with subcode but I didn't look > that closely.Amusingly, googling for cdparanoia subcode turns up...me and Will, talking about whether it will do it or not. :-)That's hilarious. I'd really love to find a way to either play CDG straight from a CD or be able to rip just one track (during a show, it'll be a pain in the ass if someone brings their own disc to play but doesn't hand it to me until it's their turn to sing ... "yeah, it'll be about ten minutes before you can sing this because my computer has to read the whole disc first") -- Looking for something to read? Visit http://willfe.com/ ... it's easy, safe, and fun for the whole family! Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
On Sun, Jun 25, 2006 at 06:46:05PM +0100, Drew wrote: > > Well, having finally gotten SuSE 10.0 onto my laptop and the 100GB > > drive (which freed up the 80GB to go in the external chassis), I'm > > about to start ripping my 400 disc library -- which includes a lot of > > brands, though only a couple Sound Choice and Music Maestro discs -- so > > I guess I can A/B compare them, and see what I get. Even a 10% speedup > > is worth it on 400 discs. :-) > > I'm pretty sure you'll see a speed increase. As far as ripping all 400 > disks my code is missing some important features that cdgrip.py has. The > main ones are the track name lookups and the ability to use lame instead > of oggenc. Ah. Well, ogg is fine with me, as long as the player will track it. FreeDB is a bit more important -- you'd be surprised how many karaoke CDGs are actually in there. > > I may have to buy a drive; I'm almost certain the DVD-ROM in my Compaq > > laptop (which is a Toshiba) will *not* reliably read subcode: CDRWIN > > professes itself unable to read CD+G's with it. > > > > Do we still like the Plextors best? I can't burn CD+G's or DVD's > > either at the moment, so a USB external seems the solution. > > Not sure about your drive but I have seen drives that won't read subcode > in windows with CDRWin but will work under linux with cdrdao. I'm going ot test it. > > Has anyone looked into cdparanoia? > > I couldn't find an option for ripping with subcode but I didn't look > that closely. Amusingly, googling for cdparanoia subcode turns up... me and Will, talking about whether it will do it or not. :-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail? Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
> > Yes, absolutely. I would like to know if anyone else has successfully > > compiled and test it. > > Well, having finally gotten SuSE 10.0 onto my laptop and the 100GB > drive (which freed up the 80GB to go in the external chassis), I'm > about to start ripping my 400 disc library -- which includes a lot of > brands, though only a couple Sound Choice and Music Maestro discs -- so > I guess I can A/B compare them, and see what I get. Even a 10% speedup > is worth it on 400 discs. :-) I'm pretty sure you'll see a speed increase. As far as ripping all 400 disks my code is missing some important features that cdgrip.py has. The main ones are the track name lookups and the ability to use lame instead of oggenc. > > > > My drive returns the data interleaved, so I've only ever tested rw_raw > > > mode (using the software-deinterleave) hence the note of caution in the > > > instructions for rw mode. My thinking was that the data returned in rw > > > mode would need nothing doing to it at all, it could be written straight > > > out to the CDG file as it came from the CD drive. Have you found this > > > not to be the case? Could it be that the drives concerned don't support > > > rw mode? > > > > This is exactly what I believed. I basically used what cdgrip does as my > > guide and wrote an equivalent in C. I tested it on a disk image from one > > of my drives. cdrdao reports that the drive I used can return RW info so > > I ripped a cdg disk in RW mode and then tried to split the image into > > audio and cdg files. > > > > Aside: With most of the drives I tried cdrdao reported that they could > > not extract in RW mode only RW_RAW and when I tried to extract in RW > > mode cdrdao failed without extracting anything, with a message about the > > drive not supporting RW. The one drive that did work claims to be able > > to extract RW and RW_RAW. > > I may have to buy a drive; I'm almost certain the DVD-ROM in my Compaq > laptop (which is a Toshiba) will *not* reliably read subcode: CDRWIN > professes itself unable to read CD+G's with it. > > Do we still like the Plextors best? I can't burn CD+G's or DVD's > either at the moment, so a USB external seems the solution. Not sure about your drive but I have seen drives that won't read subcode in windows with CDRWin but will work under linux with cdrdao. > > Has anyone looked into cdparanoia? I couldn't find an option for ripping with subcode but I didn't look that closely. Drew Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
On Sun, Jun 25, 2006 at 12:58:03PM +0100, Drew wrote: > On Wed, 2006-06-21 at 23:17 +0100, Kelvin Lawson wrote: > > Thanks a lot for posting your code Drew, glad to hear you got it > > working. If you don't want the hassle of packaging it up yourself in a > > release it sounds like a good addition to the cdgtools suite. I tend to > > use Python for home projects simply because I find it quicker to get > > something functional, but I see no reason why C code shouldn't go into > > cdgtools. Let me know if you're interested (cdgtools is LGPL by the way). > > Yes, absolutely. I would like to know if anyone else has successfully > compiled and test it. Well, having finally gotten SuSE 10.0 onto my laptop and the 100GB drive (which freed up the 80GB to go in the external chassis), I'm about to start ripping my 400 disc library -- which includes a lot of brands, though only a couple Sound Choice and Music Maestro discs -- so I guess I can A/B compare them, and see what I get. Even a 10% speedup is worth it on 400 discs. :-) > > My drive returns the data interleaved, so I've only ever tested rw_raw > > mode (using the software-deinterleave) hence the note of caution in the > > instructions for rw mode. My thinking was that the data returned in rw > > mode would need nothing doing to it at all, it could be written straight > > out to the CDG file as it came from the CD drive. Have you found this > > not to be the case? Could it be that the drives concerned don't support > > rw mode? > > This is exactly what I believed. I basically used what cdgrip does as my > guide and wrote an equivalent in C. I tested it on a disk image from one > of my drives. cdrdao reports that the drive I used can return RW info so > I ripped a cdg disk in RW mode and then tried to split the image into > audio and cdg files. > > Aside: With most of the drives I tried cdrdao reported that they could > not extract in RW mode only RW_RAW and when I tried to extract in RW > mode cdrdao failed without extracting anything, with a message about the > drive not supporting RW. The one drive that did work claims to be able > to extract RW and RW_RAW. I may have to buy a drive; I'm almost certain the DVD-ROM in my Compaq laptop (which is a Toshiba) will *not* reliably read subcode: CDRWIN professes itself unable to read CD+G's with it. Do we still like the Plextors best? I can't burn CD+G's or DVD's either at the moment, so a USB external seems the solution. > When I had extracted the .bin image I ran it through dcdgrip to split it > but the results were not as expected. The CDG info was garbage and the > audio was very badly distorted (like samples were missing and maybe cdg > data was still present) > > There are several possible reasons this could have happened. > > 1. The drive was returning incorrect data. However the fact that the > audio was distorted suggests to me that it was not just returning RW_RAW > data because that would have resulted in normal audio and garbage cdg. > > 2. cdrdao is doing something to the data. Has anyone looked into cdparanoia? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail? Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
On Wed, 2006-06-21 at 23:17 +0100, Kelvin Lawson wrote: > Thanks a lot for posting your code Drew, glad to hear you got it > working. If you don't want the hassle of packaging it up yourself in a > release it sounds like a good addition to the cdgtools suite. I tend to > use Python for home projects simply because I find it quicker to get > something functional, but I see no reason why C code shouldn't go into > cdgtools. Let me know if you're interested (cdgtools is LGPL by the way). > Yes, absolutely. I would like to know if anyone else has successfully compiled and test it. > > 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 is good stuff. Thanks I was quite pleased with that bit :) > My drive returns the data interleaved, so I've only ever tested rw_raw > mode (using the software-deinterleave) hence the note of caution in the > instructions for rw mode. My thinking was that the data returned in rw > mode would need nothing doing to it at all, it could be written straight > out to the CDG file as it came from the CD drive. Have you found this > not to be the case? Could it be that the drives concerned don't support > rw mode? This is exactly what I believed. I basically used what cdgrip does as my guide and wrote an equivalent in C. I tested it on a disk image from one of my drives. cdrdao reports that the drive I used can return RW info so I ripped a cdg disk in RW mode and then tried to split the image into audio and cdg files. Aside: With most of the drives I tried cdrdao reported that they could not extract in RW mode only RW_RAW and when I tried to extract in RW mode cdrdao failed without extracting anything, with a message about the drive not supporting RW. The one drive that did work claims to be able to extract RW and RW_RAW. When I had extracted the .bin image I ran it through dcdgrip to split it but the results were not as expected. The CDG info was garbage and the audio was very badly distorted (like samples were missing and maybe cdg data was still present) There are several possible reasons this could have happened. 1. The drive was returning incorrect data. However the fact that the audio was distorted suggests to me that it was not just returning RW_RAW data because that would have resulted in normal audio and garbage cdg. 2. cdrdao is doing something to the data. 3. The data returned is not in the expected order. (What we were expecting is audio sectors followed by DEINTERLEAVED cdg info) 4 It is possible that the drive (or the driver) is wrong about it's own capabilities and is corrupting data in an unpredictable way. I'm tempted to believe that 3 is the correct answer and that the returned data is not in expected order. (I have had a look through the data with a hex viewer but can figure out what it's putting where) I must admit I haven't tested cdgrip.py and I might get round to doing that today (after the football). I'll post the results if I do. Drew Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
Hello Folks, Thanks a lot for posting your code Drew, glad to hear you got it working. If you don't want the hassle of packaging it up yourself in a release it sounds like a good addition to the cdgtools suite. I tend to use Python for home projects simply because I find it quicker to get something functional, but I see no reason why C code shouldn't go into cdgtools. Let me know if you're interested (cdgtools is LGPL by the way). > 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 is good stuff. > 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?) I just had a look through the cdrdao man page and to my surprise there doesn't seem to be an option to rip single tracks. Anyone know of any other suitable rippers? >>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? My drive returns the data interleaved, so I've only ever tested rw_raw mode (using the software-deinterleave) hence the note of caution in the instructions for rw mode. My thinking was that the data returned in rw mode would need nothing doing to it at all, it could be written straight out to the CDG file as it came from the CD drive. Have you found this not to be the case? Could it be that the drives concerned don't support rw mode? Cheers, Kelvin. All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 ___ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
Re: [Pykaraoke-discuss] New ripper
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 l
Re: [Pykaraoke-discuss] New ripper
On 6/6/06, Drew <[EMAIL PROTECTED]> wrote: Hi all,I posted a few months ago with a plan about building a karaoke systemusing pykaraoke. One thing I noticed was that cdgrip was a little slowto 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 oggusing 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 fromthe language of choice)* It is a little bit faster (maybe 20%) probably mostly as a result ofbeing 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 needsto 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 althoughI 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 onthe 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 CThis 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 Ithink the same option in cdgrip might also be broken (mostly because Ijust 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 rwoption are returning something odd. It's hard to track down the sourceof 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 towork 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 CRCalgorithm 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
