(Last updated: August 27, 2020)
My car's CD player supports CD-TEXT, as does my beloved Rio Volt SP250 mp3 CD player, and I've found that I always appreciate it when companies include CD-TEXT on the discs that I buy. Naturally, I eventually decided I'd like to include that on discs that I was burning for myself. There's not a lot of documentation on doing so, as CD-TEXT support is, in my experience, generally nonexistant in most hardware, and most people probably don't care too much about it. It took me a few hours to investigate some options and find out what actually worked for me, so perhaps if Google picks up this page, I can save somebody those few hours that they'd otherwise spend doing the same.

GUI Tools

I'm sure that there are many GUI tools which can do this. I know for sure that k3b supports it (though I've never tried it myself), and I assume that there are many others as well. I tend to spend most of my Linux time on the Commandline, though, and that's where I wanted to stay, so I didn't investigate this at all. If you have no such qualms about GUIness, you'll probably have an easy enough time with it. (NOTE: It's possible that even with a GUI tool, you may end up needing to mess around with the driver being used to do the burning - see my second note at the end of the cdrado section.)


cdrecord, part of cdrtools, apparently supports CD-TEXT via two methods:
  1. *.inf files created by cdda2wav
    These .inf files aren't documented terribly well (that I've found, anyway), and the files I looked at after a test cdda2wav run looked quite cryptic. The cdrecord manpage also had this to say:
    If this  option  is used,  the  pregap  size information is read
    from the *.inf file that is associated with the file that contains
    the audio  data for a track.
    I wasn't terribly keen on having to worry about the inf files changing behavior in how cdrecord was writing the actual audio data, so I decided not to go this route. Plus, it looked like I'd need a .inf for each track? Not for me.
  2. CUE sheets
    CUE sheets are very well documented (see the Wikipedia article on them) but everything I've seen on them indicates that you've got to include timing information in them (for instance, how long each track is, or at least at what point on the CD to put the data). The cdrecord manpage had this to say, in addition:
    Take all recording related information from a CDRWIN  compliant CUE  sheet file.
    Once again, I don't want to have to deal with timing issues in a file which I only want to use for defining track titles. I'm happy letting cdrecord (or whatever) do the track length calculations and the like. So, I decided not to go with this option either (which takes cdrecord out of the loop.) If I'm wrong about CUE sheets requiring this info, feel free to let me know.


So, I turned to cdrdao for this. cdrdao uses a "TOC file" to define how to burn things, and while it's not as widely-documented as CUE sheets, the cdrdao manpage is quite helpful on the matter. It also lets the program itself figure out how long the tracks are, and where to put them on the CD, which is nice. Here's a valid TOC file which defines two tracks and sets the CD-TEXT info like I want:

    0 : EN

    TITLE "A Short EP Or Something"
    PERFORMER "Imaginary Band"

    TITLE "The First Track"
    PERFORMER "Imaginary Band"
FILE "01-The_First_Track.wav" 0

    TITLE "Track TWO"
    PERFORMER "Imaginary Band"
FILE "02-Track_TWO.wav" 0
As you can see, it's pretty straightforward. It's definitely a bit wordier than I'd like to create by hand, but a few seconds in any scripting language would be enough to create a quick template.

There's a couple of important things to note in there:

Update December 2016:

It seems that at least in some circumstances, switching to generic-mmc-raw doesn't work. If you're seeing errors similar to "receiving sense code 2 on writing" (or if it's just not working at all), you may want to try using this driver option instead: --driver generic-mmc:0x10. So the full line would look something like:

cdrdao write --device /dev/sr0 --driver generic-mmc:0x10 -v 2 -n --eject toc.txt

On my own system, this doesn't seem to be required, but others have found it necessary. See cdrdao bug #180 for potentially more info. Thanks, Markus, for sending this info my way!


So, there you go. cdrdao ended up doing the trick quite nicely for me, and on my burner I had to use the generic-mmc-raw driver in order for it to work (this is where the majority of my tracking-down-the-problem came into play). Hopefully this will help someone out.

Feel free to drop me an email if you find any info out-of-date in here!



August 27, 2020
  • Fixed a couple of outdated links
December 20, 2016
  • Update to driver arguments
  • Initial version