Thomas: yes mmc_get_track_isrc_private should interpret this bit before returning and ISRC string. Please make it so.
On Sat, Apr 2, 2016 at 12:18 PM, Thomas Schmitt <[email protected]> wrote: > Hi, > > Leon Merten Lohse wrote: > > How about > > strndup(&buf[9], 16); > > instead of the additional byte? > > Yes. That's the better transition from binary to string. > > But with char buf[24], it has to be 15, not 16: > > return strndup(&buf[9], 15); > > > The function mmc_get_mcn_private() has the same code structure > as mmc_get_track_isrc_private() . So any final change in _isrc > should be mirrored in _mcn. > > > --------------------------------------------------------------- > An SCSI specs observation: > > READ SUB-CHANNEL tells by bit 7 of buf[8] whether the reply contains > a valid ISRC at all. If that bit is 0, then the reply data are not > valid. > See description of TCVAL in: > MMC-1, 5.1.12.4 "Sub-Channel Data Format (03h)" > MMC-4, 6.29.3.5 "International Standard Recording Code (ISRC)". > > So shouldn't mmc_get_track_isrc_private() interpret this bit > before returning an ISRC string ? > > Same for mmc_get_mcn_private(). Bit name in MMC is MCVAL. The > bit position is the same as with ISRC. > > > Have a nice day :) > > Thomas > > >
