Here are the steps I take to burn an audio cd under debian 4.0:

1. Run the following script in the directory containing mp3 or flac audio

For mp3:

# mp32wav 2.6.2001 / uk
#
for i in *.mp3
do
wavfile=`echo "$i" | sed s/\\.mp3/.wav/`
lame --decode "$i" "$wavfile"
done

For flac:

#!/bin/bash
for i in *.flac
do
flac -d "$i"
done

Then, I run cdrecord:

cdrecord -v dev=/dev/hdc -dao -pad -audio *.wav

This worked fine for months, until this morning when I burned a cd and the track information (TOC) given was indeed not the same as what the tag information was on the source mp3. The same for flac: It gave "お菓子CD No.3-06 ドカベン", for what should have been "Jerusalem" and "こおろぎ'7" for what should have been "ELP".

Any help/suggestions will be appreciated.

Very odd. I don't see anything in there for handling tag information, or for adding cd-text to the final disk. All these commands do is convert the tracks to .wav files and then burn them to cd-audio. There shouldn't be any track information at all, according to this.

There must be something else going on here. Is this everything? The stuff you posted isn't even a proper script. Are these two separate scripts? Is there anything else you do outside of running these commands?

OTOH, Google shows that "Okashi CD No. 3-06 Dokaben" is the name of an anime CD single.

Thanks for the reply.

These are two separate scripts. If I want to burn flac files I run the one for flac, if mp3 I run the one for mp3. Then I run the cdrecord command.

Up until yesterday the burned cd would have all the correct tag info, without doing anything outside of the process described above.

Around the time I burned the cd I found the following in syslog:
****
Feb 7 11:41:34 CPE0007e93d1b62-CM00152fc76afa NetworkManager: <debug info>^I[1234024894.396580] nm_hal_device_removed (): Device removed (hal udi is '/org/freedesktop/Hal/devices/volume_part_1_size_427292672').
Feb 7 11:43:33 CPE0007e93d1b62-CM00152fc76afa kernel: cdrom: This disc doesn't have any tracks I recognize!
Feb 7 11:43:33 CPE0007e93d1b62-CM00152fc76afa NetworkManager: <debug info>^I[1234025013.902019] nm_hal_device_added (): New device added (hal udi is '/org/freedesktop/Hal/devices/volume_empty_cd_r').
****

I googled kernel: cdrom: This disc doesn't have any tracks I recognize! and found posts of it, but no explanations.

Once again, thanks for the reply.

After some more experimenting I have discovered that this problem only happens with certain files. I guess it has something to do with the tags on the flac/mp3 files.

Well, as I said, I can't understand how ANY of your disks can have track info in them. The only way I know of to store such things on a CD is with cd-text, and your cdrecord command doesn't have that enabled. And since the input is .wav, and .wav doesn't have any metadata capability, there's nowhere for it to get the track info in the first place. And your two scripts don't touch the metadata either, as the the only thing they both do is decode the tracks to .wav. Finally, the majority of CD players ignore cd-text anyway.

I'm going to make an educated guess here that what you're calling the "TOC" info is in fact coming from a CDDB lookup in your music player. Most software players these days do automatic lookups in the online CD DataBase* to get track info, which contains listings for the vast majority of commercial disks. But it's hit-or-miss as to whether a burned copy will have a correct disk ID. Straight copies can often match correctly, but not always, and may instead give you either nothing or a false match in return. And mixed disks will certainly fail.

Frankly I'm surprised that copies match as often as they do.

=====
*Actually, most of them use FreeDB or MusicBrainz these days, since the original CDDB was bought out and the new owners implemented some unfavorable terms of service.)

I suspect it is the CDDB stuff you mentioned. When I loaded the cd into a cd player that uses cddb the "garbled" name came up, first on the list. Now, I don't know how this is happening. I'm not doing anything when I burn to invoke a cddb lookup, at least explicitly.

I burned another cd using the steps mentioned above and it came out with the artist and track information that matched the songs.

So I retried the song that was causing problems and the information was, again, incorrect. Very odd, indeed.

The burn has nothing to do with the CDDB lookup, other than in creating the disk ID. It's your player that takes the ID number and sends it to the database for matching.

Now I haven't the foggiest idea how the CD's ID number is determined. If you make an exact copy from clean files it will sometimes (and surprisingly, in my opinion) come out the same as the CD it was originally ripped from, but it's not at all guaranteed.

If your CD player has local CDDB ability (some programs have can use a local database, usually found at ~/.cddb), you could add the correct data to it, and configure the player to read from there instead.

I get it now. My mistake was in thinking that the information was somehow coded into the disk. Thanks for your help and replies.