Hey Kelvin, > You could ascertain whether it was the MP3 encode by fiddling with the > cdgrip() function in cdgrip.py. It saves a raw WAV file, then encodes to > MP3. If you're comfortable modifying the Python code then you could try > omitting the MP3 encode step to see whether the raw WAV works (you can > play WAV files in PyKaraoke but obviously they take up a good deal more > room). If endianness is to blame, you can also pass different parameters > to lame to swap endianness.
I kinda thought it might be this easy, but I hadn't had a chance to look at the code yet. Just did so and after fiddling with a few lame options, I found that --big-endian did indeed fix the problem. BTW, it's not WAVs that are stored temporarily, but rather raw PCM data, so I think that's what gives lame a hard time since it can't auto-detect. I wonder what cdparanoia uses to autodetect the endianness (and any number of other parameters)...? Anyway, I'll take this moment to humbly submit two feature requests for cdgtools: 1. Encode real WAVs by default and optionally encode MP3s. I personally prefer not to use MP3 at all, both due to patent reasons and because OGG is just better. A switch to encode OGGs would be great as well. 2. Add an option to cdgrip to allow one to pass switches/options to the underlying encoding programs. It would let people like me get around any endian or signed issues that crop up. Thanks again for all of the hard work! tim ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Pykaraoke-discuss mailing list Pykaraoke-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
