The following bug was reported. I'd appreciate it if someone with OSX could verify the information reported is correct. I'm also not sure if the suggested fix is correct (changing "<=" to "<" on lib/drivers/osx.c line 1206 and/or line 1249.
Part of the complication I think comes from the fact that we need to get "lead-out" track information (i.e. where's the end of the CD) and probably that too may be stored in the pTrackDescriptors array. If not, where else would it be? The bug poster merely says that the *total* number of tracks reported is one too large. But that is calculated as last_track - first_track + 1. So is it the last_track or the first_track that's wrong? Is this only on audio CD's or other kinds of CD's as well? Thanks in advance. > cd-info for Mac OS X 10.4 always reports wrong track number with any > AudioCD. > > The root cause is read_toc_osx() in lib/driver/osx.c, I guess. > In read_toc_osx() > for( i = 0; i <= p_env->i_descriptors; i++ ) > is wrong. > for( i = 0; i < p_env->i_descriptors; i++ ) > works correctly because the number of elements in pTrackDescriptors[] array > is p_env->i_descriptors, not (p_env->i_descriptors + 1) > > _______________________________________________________ > > Reply to this item at: > > <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15787> _______________________________________________ Libcdio-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/libcdio-devel
