CD track recognition bug

SDL Development
1

I’ve got an odd problem with SDL’s CD info (1.1.6). Any CD that I’ve
copied on my Windows system (using Adaptec CD Creator and a Ricoh
DVD/CDR) does not return a valid ‘type’ value in the SDL_CDtrack struct.
Audio tracks return ‘2’ and data tracks return ‘6’. The source CDs
return the proper values of ‘0’ (SDL_AUDIO_TRACK) and ‘4’
(SDL_DATA_TRACK) for audio and data.

Any ideas why?

Cheers,
Mark----------------------------
Mark B. Allan
http://www.reptilelabour.com

2

I’ve got an odd problem with SDL’s CD info (1.1.6). Any CD that I’ve
copied on my Windows system (using Adaptec CD Creator and a Ricoh
DVD/CDR) does not return a valid ‘type’ value in the SDL_CDtrack struct.
Audio tracks return ‘2’ and data tracks return ‘6’. The source CDs
return the proper values of ‘0’ (SDL_AUDIO_TRACK) and ‘4’
(SDL_DATA_TRACK) for audio and data.

Any ideas why?

The Windows code explictly sets the value based on the Windows multimedia
track information, and the Linux code sets the value from the cdte_ctrl
field in the TOC entry. I’m just using the value, but it’s possible that
I should be looking at the bit rather than returning the value.

What platform does the bug show up on?

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

3

Sam Lantinga wrote:

I’ve got an odd problem with SDL’s CD info (1.1.6). Any CD that I’ve
copied on my Windows system (using Adaptec CD Creator and a Ricoh
DVD/CDR) does not return a valid ‘type’ value in the SDL_CDtrack struct.
Audio tracks return ‘2’ and data tracks return ‘6’. The source CDs
return the proper values of ‘0’ (SDL_AUDIO_TRACK) and ‘4’
(SDL_DATA_TRACK) for audio and data.

Any ideas why?

The Windows code explictly sets the value based on the Windows multimedia
track information, and the Linux code sets the value from the cdte_ctrl
field in the TOC entry. I’m just using the value, but it’s possible that
I should be looking at the bit rather than returning the value.

What platform does the bug show up on?

Linux. Havn’t tested it on Windows yet.

Cheers,
Mark----------------------------
Mark B. Allan
http://www.reptilelabour.com

4

The Windows code explictly sets the value based on the Windows multimedia
track information, and the Linux code sets the value from the cdte_ctrl
field in the TOC entry. I’m just using the value, but it’s possible that
I should be looking at the bit rather than returning the value.

What platform does the bug show up on?

Linux. Havn’t tested it on Windows yet.

Try the latest CVS snapshot, it should work correctly now:
http://www.libsdl.org/cvs.html

Thanks! :slight_smile:
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

5

Sam Lantinga wrote:

The Windows code explictly sets the value based on the Windows multimedia
track information, and the Linux code sets the value from the cdte_ctrl
field in the TOC entry. I’m just using the value, but it’s possible that
I should be looking at the bit rather than returning the value.

What platform does the bug show up on?

Linux. Havn’t tested it on Windows yet.

Try the latest CVS snapshot, it should work correctly now:
http://www.libsdl.org/cvs.html

Looks good!

Cheers,
Mark----------------------------
Mark B. Allan
http://www.reptilelabour.com