CAA: Christian Anime Alliance

I have made audio CDs using Nero (for more proper CDs (and more proper grammar...)) and Windows Media Player 10 (for quick compilations, etc), and while I haven't had any problems making them, I have several questions:

1. Nero lets you name tracks and also the CD title and artist for CD TEXT. This is supposed to be displayed in compatible portable or car CD players, but I've never owned a CD TEXT player or seen it in action. However, one would expect a computer's CD drive to be able to read this info and use it as track title info when ripping. I use WMP for ripping and general media player type things, and it doesn't do this. It would seem the logical thing to do; to read off the CD TEXT that's already there! So why doesn't it do this, and is it a limitation of the CD drive being unable to read it, or WMP doesn't want to read it?

2. When ripping with WMP, you can change the track titles, artists, and genres, BUT NOT ALBUM NAME!! This has puzzled me for some time as to why this is not possible to do, or not easy to find out how to do. Can anyone shed some light here? I know you can change it after it's ripped but not before...

3. When you put a commercial bought CD, it downloads tracks off an internet database somewhere. It would seem the logical way for this to work would be store a unique ID code on each CD which is all it needs to send to the database server, which then sends back the relevant track listings. Can anyone confirm this to be true? How does this relate to homemade CD audios? Do they get unique IDs? How do they know the ID is unique when they make the CD? I have had the wrong track listing brought up before.... has anyone else had this happen?

4. Why isn't space used for play/pause? Why is it CTRL+P? Did they start learning shortcut keys from Apple?

I can't answer 1 or 2 because I deal with a superior platform.

The answer to 3 is, there is no "ID." CDDB -- the database you're indicating -- is a hash "checksum" based on the CD-TOC, which is the Table of Contents embedded into every CD containing the length of each track, offset of each track and number of tracks. Data tracks count. There are also two pseudo-tracks, 999 and 1000, which are used for lead-out and error information (if any) respectively. Therefore, if you were to make a CD with tracks of exactly the same length in exactly the same positions on a disc (down to the single data frame), you *could* get a hash collision, but this requires specialized equipment and is just about impossible in a practical sense.

And 4, I know Apple didn't design it. If it were, it would be Command-P.

I'm not familiar with the use of CD Text for the naming of tracks when CDs are ripped, but I read a little bit about it, and discovered that other pieces of ripping software (i.e. dbPowerAmp Music Converter) can read the CD Text information and use it for track information. This is simply a WMP problem.

And don't ask why WMP has wierd shortcut keys. Why does Winamp use the x key for play? Media players just use wierd shortcuts sometimes.

shooraijin wrote:I can't answer 1 or 2 because I deal with a superior platform. ]
1 & 2 - It's hardly platform related; it's program specific. They're the only problems I've found with WMP, other than that, it's served it's purpose well.
3 - Ah, that makes sense, and would be a *bit* [read: heaps] easier than trying to manage ID code collisions...
4 - That was more a reference to "use a two-button shortcut when a single button shortcut would suffice".

Puritan wrote:I'm not familiar with the use of CD Text for the naming of tracks when CDs are ripped, but I read a little bit about it, and discovered that other pieces of ripping software (i.e. dbPowerAmp Music Converter) can read the CD Text information and use it for track information. This is simply a WMP problem.

And don't ask why WMP has wierd shortcut keys. Why does Winamp use the x key for play? Media players just use wierd shortcuts sometimes.

Well it's puzzling why they didn't chose to implement it...


EDIT: For #3 - 'just about impossible' to get identical TOC? Or same hash code? Hash tables take a large range of possibilities and produce a much smaller domain, so the chance of a collision is much more likely than having identical TOCs....

I have in fact seen several instances of CDs being incorrectly identified, or of mix CDs being identified as regular CDs, or of music from iTunes burned to CDs having the correct track listings when ripped to MP3s. Either I have just been lucky, or there appear to be enough CDs in some databases that the probability of seeing a collision is pretty high.

Warrior4Christ wrote:4 - That was more a reference to "use a two-button shortcut when a single button shortcut would suffice".

EDIT: For #3 - 'just about impossible' to get identical TOC? Or same hash code? Hash tables take a large range of possibilities and produce a much smaller domain, so the chance of a collision is much more likely than having identical TOCs....

Yeah, but w/r/t #4, we now use dual button mice now too.

Seriously, on #3, I meant TOC. However, the hash must be pretty good, because for the millions of CDs catalogued in CDDB, I haven't heard of a collision.