Re: [linux-minidisc] First patch for write support on HiMD available

[manner.moe@gmx.de]

>Betreff : Re: [linux-minidisc] First patch for write support on HiMD available
>Gesendet: 11.03.2011 10:30:32
>An : "manner.moe@gmx.de"
>Von: "Adrian Glaubitz <glaubitz@physik.fu-berlin.de>"

>----- Originale Nachricht -----

>On Mar 11, 2011, at 6:40 AM, manner.moe@gmx.de wrote:
>> 
>>> I added a
>> 
>>>> setbeword16(himd->tifdata + 0x100, himd_track_count(himd) + 1);
>> 
>>> as a dirty hack at the end of "himd_add_track_info" which forces an increment
>>> of the track count in the track index file. QHiMDTransfer shows the proper
>>> number of tracks now, what makes me wonder, however, is that the track info for
>>> the added track is not set at all, e.g. the track info data is empty for that
>>> track in QHiMDTransfer while himddump shows the complete and proper
>>> track information.
>> 
>> You have to add an entry in the play order table, too (see trackslot section 
>> in libhimd) at 0x102 + 2 x index.
>> QHiMDTransfer uses trackslots, so we have to create one.

>Ok, I had no idea about the trackslots. Thanks for letting me know! I will
>try what you suggested.


>Adrian

At ofset 0x0100 in the trkidx file the play order table is stored.
First word is the track count an the next words is a map containig the track 
numbers and the order they will appear in the track list.
Second word is the first physical track and the value is the track number of 
this track in the track list.
Third word ist the second phys. track, .... 
An Example: We have 3 Tracks, so the play orter table should look like this
00 03 00 01 00 02 00 03 00 00 00 ...

If we move track 3 to the first position we have
00 03 00 03 00 01 00 02 00 00 00 ...

It´s a kind of map between the physical order of tracks in the atdata file 
and the order of tracks shown in the playlist.

Thomas