AIFF files on Audio CDs not really AIFF?

G

gadgetking

Registered
Does anybody have any insight on this?

Here's the situation. I've compiled the LAME 3.87 beta under OS X PB so that I can do MP3 encoding. LAME will take AIFF, WAV or raw PCM files as input and output MP3 files.

If I try to encode directly from an audio CD, LAME assumes it's a raw PCM file and the resulting MP3 is all white noise. However, the finder shows all the files on CD as AIFF, not raw PCM. If I boot back to OS 9 and use SoundJam to encode a file on the CD to AIFF (under classic, SoundJam doesn't see the CD :-( ) I can then encode that AIFF file to MP3 using LAME.

So, what's going on here. In general, files on CD are not AIFF, but the OS X Finder says they are. Anybody have a clue on this?

Thanks!
 
The files are actually AIFF-C files. I've had no luck doing anything
with them so far; I've played with LAME and SOX, hacking them a bit
to accept AIFC as a synonym for AIFF and making (IIRC) SOX a bit
more lenient about the size of the common cluster, but with no luck.
Once you get that far, you find out that the block offset in the sound
cluster is non-zero, so the software gives up on them. I've not fiddled
with the block offsets yet.

I've also heard a rumor on the net that the data is stored in the files
bigendian. I've not verified this.
 
I successfully created an mp3 using lame last night. I had to make a couple of
quick hacks to get_audio.c. The following descriptions refer to lame3.87beta.

- Make it look for an 'AIFC' tag instead of 'AIFF'. See line 734.
- Make it ignore the block alignment offset. I.e., delete lines 869 through 873.
- Use the '-x' command line switch to force it to byteswap the data.

Open source roolz, dood!
 
Hey thanks for the info! I was trying to avoid hacking LAME, but I'll probably try your suggestions.

It is way cool to be able to change the code so the product will do what you want!
 
You must log in or register to reply here.
Back
Top