HiMDDiskFormat

HiMD-Media are read and written in Mass-Storage mode. So one only needs to know the on-disk format to be able to read/write from Linux. The disks are formatted with a standard FAT16-filesystem but with a 2kb-sectorsize. Once the disk is attached to a PC it can be used as a normal mass-storage device (format is superfloppy, i.e. no partitions). When SonicStage (or HiMD Music Transfer on the Mac) is started, the minidisc is unmounted by SonicStage and thus inaccessible by the operating system. This is necessary because SonicStage uses special SCSI read/write-commands to communicate with the MD-Walkman. This is probably necessary for a secured data-exchange between Walkman and the host PC.

Disk-Images of various MiniDiscs for testing

md_with_one_mp3.img.gz - Image of a 305MB HiMD containing one MP3 - Disk-ID: 0202000002000102A36E0000CAEF24F1 - created with Sony MZ-RH10 and HiMD Music Transfer for Mac
md_empty.img.gz - Image of a freshly formatted 305MB HiMD - Disk-ID: 0202000002000102A36E000040E633F2 - created with Sony MZ-RH10 (built-in format functionality)
himd_with_dozens_of_mp3s.img.gz - Image of 1GB HiMD containing dozens of MP3s - Disk-ID: 02000000000006121202000000718002 - created with Sony MZ-RH10 and SonicStage 4.3/4 Japanese
mdw60.img.gz - Image of 220MB MD (MD-W60) containing one PCM-recording - Disk ID: 020200000200010228310000779D3C0A - Recorded with a Sony MZ-NH600 via Toslink, recording is untitled
md_with_one_pcm.img.gz - Image of MD containing one PCM-recording - Disk ID: 0202000002000121B40E0000F9EFA991 - Recorded with a Sony MZ-RH1 from input (thus with suspected less encryption), recording is untitled
md_with_atrac3.img.gz - Image of MD containing three ATRAC3-recordings with 105 kbit/s recorded with MZ-RH1 - Disc ID: 0202000002000121B40E0000B3AFA5B0
mixedmode_md.img.gz - Image of MD containing 4 Tracks, PCM/ATRAC3/MP3 recorded with MZ-RH1 - Disc ID: 0202000002000121B40E0000F9EFA991
md_with_one_pcm_nh700.img.gz - one PCM-recording transfered with SonicStage onto a MZ-NH700
md_with_one_pcm_rh1.img.gz - one PCM-recording transfered with SonicStage onto a MZ-RH1 (same PCM as with NH700)

The DiskID

The disk-id is the unique identifier of each HiMD and is read using special SCSI commands. A small program-code to fetch the disk-id can be found here:

http://users.physik.fu-berlin.de/~glaubitz/linux-minidisc/minikey.c - Read the disc-ID of a MiniDisc in Linux
http://users.physik.fu-berlin.de/~glaubitz/linux-minidisc/mp3key.c - Generate MP3-encryption key from DiscID

The disk-ID is used to encrypt the (audio-)data on the HiMD. The latest versions, however, can be found in the git-repository.

Filesystem Issues with some Models on Linux

It has been observed, that some older HiMD-Walkman (MZ-NH600 and MZ-NH900) cause some trouble in Linux (but not in Windows) when listing the contents of "HMDHIFI"-directory:

root@z6:/mnt/hmdhifi> ls
ls: cannot access n/n╒ì╬∩_._▐]: No such file or directory
ls: cannot access ▌▀eu╒╟╜«.eΘ«: Input/output error
ls: cannot access ╡m ┘╟_╜.■√╓: Input/output error
ls: cannot access ·jl_φ╠ _.▐₧▐: Input/output error
ls: cannot access  ▀m▀╒╩²«.oφ¡: Input/output error
ls: cannot access ■_▀öª▀_┐.≈√╒: Input/output error
ls: cannot access ■\▀┐▐»^.²²ƒ: Input/output error
ls: cannot access j/no¡╬δ_.■▀φ: No such file or directory
(...)
?             ²_▀¥∩δ ┐.÷√▐  ª╜²⌡o▌≈▀.┐nw  ª▌╜ {▌⌡▀.▌mg  jont▌╬╧_.▐₧ì  n»j]φ∞δu.▀▀∞  ^on▌═nδ_.▀₧φ  ■\▀▀▐»z?.²φ▀  √ƒ╒▌╧▌ⁿ∩.εº▌  ⁿ ▀╣≈█_┐.≈█▀  ▐\ █▀»z .²∙╫
?             «∙╜²}▌µ┘.▀εe  ª╗╜²{▌≈▀.┐εe  ▀▀e▀_╧▀º.nφ╝  k/l]¡─√_.▐ƒ▌  n/lu¡╧√_.▀╒═  ▀▐ou╓ñ ».nΘ¼  z/nu═╠δ_.▐╛▌  εoj]═fδ].▀ƒ▄  ≈\ █▐½^{.² ƒ  ⌡▀ ╣≈δ]┐.▀√▌
00010012.hma  ²ε▀╜╓δ_».■[₧  ª╗╜²{▀σ².¥┼g  ▌▀eu╒╟╜«.eΘ«  «¥╜⌡k▌÷▌.┐φe  n-n╒═╬█^.▐ƒ╪  ▀▐ouuº º.~¡«  ⌡\┐▀▀»z?.φδ▀  εonu▌╬√?.▀▀╛   ▀╡▌╧╒²∩.∞╖┼   ┐▌∙╧]╝δ.Ωº▌
_0010012.hma  «█∙²?¥╖▐.╜∩   ª╗∙²{▌σ².ƒεu  ▀▀e]╫╟═».∩Θ╜  √█╜∙╧lⁿ⌐.l÷═  n»n▌∞╬√_.▐₧▌  ╜█o]u╧ ª.oφ«  ▐\▐▀▀»z .u²ü  εo ▌╧╦_º.µ√▀   ▀euu╟²«.jφ¼  ■_ ¥τk_╖.µ√▐
■\┐▌▐½z?.²√ù  ²▀ ╣▀╦█».■√₧  ª╜╜²}▌≈ .▀∩g  ⁿ_▀¥g╦_┐.■√▀  l/l┼ì╬δ].▀ƒ\  n/n╒ì╬∩_._▐]  ⁿ]▀▌»▀_┐.t√▐  ■\┐▀▌»z .⌡ ƒ  ε╬▀▌τ╦[».■√▀   ▀m▀╒╩²«.oφ¡  ∞[ ▌τδ ».⌠√▀
■\▀┐▀½z?. ▀┐  ■² ╣∩δ ┐.⌡√▀  ª╗▌¡k╜╖▌.▀εg  ·jl_φ╠ _.▐₧▐  l»ne¡e█u.▐₧▄  n/n╟¡l√_.▀ƒ]  ■t▐█▀∩^?.²²ƒ  ⌡∩▀▌╟δ_┐.≈∙▐  ╝_▀▌τ╦^┐.ε·╓  ■_ ö∩╦]┐.≈√▌  ⁿ▐ ▌τ╦_┐.σ√╓
■\▀▀▐½z .⌡ ƒ  ▐\■▀▐»^². φƒ  ª√∙╜o¥╡▌.ƒ∩w  j/n─¡╧∩_.▐▀▌  ~»lw═╠ u.▀ƒ╩  n/nu═n█_.▀ƒ╧  trkidx01.hma  δnnu¡dδ_.\┐■  ∩_▀¥τ ]┐.÷√╫  ⁿ▀ ö╟╦]╡.÷[▐   ┐▌∙╧▌ⁿ».Ωτ²
ⁿ²▀▌∩╦_╖.╒√▀  ²_ ╣ ╦_┐. √▀  ª█╣⌡o¥≈█.┐■τ  j»n┼═╠╧].╘ƒ▌  mclist01.hma  ▀█n]t╧²«.εφ╜  trkidx02.hma  ÷_▀¥╧δ_º.÷{▐  &╜╜φk¥⌡▌.ƒ∩g  ⁿ╬ ╜╟╦_º.µ{▐  ⌡] ¥▀√_┐. █▀
■\▀┐▐»^?.²²ƒ  √█⌡┘╧▌╜».·ª▌  atdata02.hma  j∩n▌¡╠√_.▐ƒ▌  mclist02.hma  ^/n╫═╠δ]._▀²  ÷\■▀▀»┌?.⌡▀ù  ⁿ]█┘╞δ_╜.⌠y▐  φ∩n╫╜╬▀_.▐┐▌  «¥╜ o▌º▀.²φg    ╜┘å╒■Θ.ε╡▌
█▀╜²╧e²φ.∞º═  ª╣²²m▌÷▌.▌d⌡  ª█⌡┐}▌σ▀.²∩σ  j/nm╠─Ω_.\▐î  _mdhifi.hma   ∩»n]¡ε√_.▀ü▌  ■\₧▀▐∩z}.}²ƒ  δφn╫¡╞√_.▐┐▌  √▀¡∙═╘∞».Ω╖═  ■ ▀╜ùδ_».╓[▐  ■_ ▌ δ▀╜.≈√▀
²o ╜≈√_».⌡[▀  ª╣²∩m▌ñ².▀σe  ª┐╜╜?▌≈▀.▌∩τ  j/no¡╬δ_.■▀φ  ╡m ┘╟_?╜.■√╓  ■_▀öª▀_┐.≈√╒  ÷\┐█▀»z².²√ƒ  ■}▀¥╟╦_».ε{▐  Ω»n▄═╬δ].▐ƒm  ■| ╧▐»z?.⌡√ƒ  ■\  ▀»┌?.≈ ╖
²o ▌τ█_».ε{₧  ª┐┘²o▌÷².█∩e  ª√╜»?▌τ².╜∩σ  j/n▄═╠φ].▐₧┌  ╬-n┼╠╠█_.▐▐═  ▀▀o]■╟┐ª.oφ╣  ÷\┐█▀»z?.⌡²ù  ε/n╓═╬δ].▐₧▄  ▐\ƒ╗▀»^?. √ƒ  ÷\ ▀▀∩z?.} ┐
root@z6:/mnt/hmdhifi>

However the important files can still be accessed properly. The kernel suggests that something is wrong with the FAT:

[1213211.340236] FAT: Filesystem panic (dev loop0)
[1213211.340244]     invalid access to FAT (entry 0x0000ffe5)
[1213211.340248]     File system has been set read-only
[1213211.340579] FAT: Filesystem panic (dev loop0)
[1213211.340585]     invalid access to FAT (entry 0x0000ffe7)
[1213211.340810] FAT: Filesystem panic (dev loop0)
[1213211.340810]     invalid access to FAT (entry 0x00005fde)
[1213211.340810] FAT: Filesystem panic (dev loop0)
[1213211.340810]     invalid access to FAT (entry 0x0000fbef)
[1213211.340810] FAT: Filesystem panic (dev loop0)

and

root@z6:~> fsck.vfat /amd/z6/0/mdw60.img 
dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN
/HMDHIFI
  Has a large number of bad entries. (245/268)
Drop directory ? (y/n)

It has not yet been confirmed what causes these errors. All we know is that they apparently only occur with older models and that the filesystems list fine in Windows. Probably some undocument FAT-features ?!?

Files

The following files can be found on a freshly formatted HiMD (MiniDisc mounted to /mnt) in the directory "HMDHIFI". The root-directory of an HiMD contains this folder only and a zero-byte file called "HI-MD.IND" which presumably is only meant to be an identifier for a HiMD-disc.

root@znote2:/mnt/hmdhifi> md5sum /mnt3/hmdhifi/*
64c228b7c4c1b02b6c2f1c11bc4148e6  /mnt3/hmdhifi/00010012.hma <---- EKB (key container) for standard HiMD keys
5363c96604a0db55e0fafc787385e36b  /mnt3/hmdhifi/_0010012.hma <---- Backup of EKB
d41d8cd98f00b204e9800998ecf8427e  /mnt3/hmdhifi/atdata01.hma <---- Containerfile containing all audio data
bb7df04e1b0a2570657527a7e108ae23  /mnt3/hmdhifi/_clist01.hma <---- Backup of Keyfile for Digital Rights Management
28147b60982b017008e75594ab2bdf00  /mnt3/hmdhifi/mclist01.hma <---- Keyfile for Digital Rights Management (unconfirmed)
bb7df04e1b0a2570657527a7e108ae23  /mnt3/hmdhifi/_mdhifi.hma  <---- Backup of the directory information of this directory
1aca77e2188f52a62674fe8a873bdaba  /mnt3/hmdhifi/_rkidx01.hma <---- Backup of last Track Index File
09b5367f524ecdbfcae6af4b3173d3db  /mnt3/hmdhifi/trkidx01.hma <---- Track Index File

The following files are found on an HiMD containing several dozen MP3-tracks:

root@burns:/mnt/hmdhifi> md5sum *
64c228b7c4c1b02b6c2f1c11bc4148e6  00010012.hma
5363c96604a0db55e0fafc787385e36b  _0010012.hma
d6c8df08ff525dd3be7a90978acb39c7  atdata02.hma
bb7df04e1b0a2570657527a7e108ae23  mclist01.hma
1fcd128c53d2bd58fd50c666b2fc6475  mclist02.hma
fafb8cbcdc3cfc70972558b6e458fd30  _mdhifi.hma
4b0f6c1dd7e893026295d4b9c3c5a8be  _rkidx03.hma
6b3e2b2c54b25b752fa831ba96a54615  text_g01.hma
cdf55e77362fb9a510207f8bb73fb826  thumbg01.hma
370af574809d15d7eaea86030200b020  trkidx02.hma
root@burns:/mnt/hmdhifi> hexedit mclist01.hma

glaubitz@z6:..sdf/HMDHIFI> ls -l
total 551904
-rw------- 1 glaubitz ag-wolf       172 2004-01-01 00:00 00010012.HMA
-rw------- 1 glaubitz ag-wolf       172 2004-01-01 00:00 _0010012.HMA
-rw------- 1 glaubitz ag-wolf 562167808 2008-09-20 18:31 ATDATA02.HMA
-rw------- 1 glaubitz ag-wolf     32768 2004-01-01 00:00 MCLIST01.HMA
-rw------- 1 glaubitz ag-wolf     32768 2004-01-01 00:00 MCLIST02.HMA
-rw------- 1 glaubitz ag-wolf     32768 2004-01-01 00:00 _MDHIFI.HMA
-rw------- 1 glaubitz ag-wolf    327680 2008-09-20 18:32 _RKIDX03.HMA
-rw------- 1 glaubitz ag-wolf     65536 2008-09-16 18:33 TEXT_G01.HMA
-rw------- 1 glaubitz ag-wolf   2097152 2008-09-20 18:12 THUMBG01.HMA
-rw------- 1 glaubitz ag-wolf    327680 2008-09-20 18:32 TRKIDX02.HMA
glaubitz@z6:..sdf/HMDHIFI>

The md5sums for all files are always the same after a fresh format except for the file "mclist01.hma" whose md5sum changes on every disk-write and is always different, even for the same minidisc used.

The file atdata01.hma is the containerfile which keeps all audio-data (this file grows once new tracks are loaded onto the disk). trkidx01.hma appears to be an index-file for the walkman.

The numeric appendices are increased from time to time. Obviously, simply adding one mp3-track with the transfer-software for Mac does not increase the numbers. It might be only increased when adding ATRAC-tracks or when adding more than one file. The files with the highest index are the only to contain valid data. When several trkidx0X.hma can be found for example, only the file with the highest index contains non-zero content (the other are zero-filled, but not zero-size).

The file mclist0X.hma

The filename "mclist01.hma" obviuosly derives from "MAClist" which is the name of one of the modules in OpenMG. MAC here stands for "Message authentication code" (see http://en.wikipedia.org/wiki/Message_authentication_code). In this case, the DRM license info of each track is considered a message, and the authenticity of these messages is confirmed by adding a 8-byte field to the track information. The MAC list contains all the MAC values of the different tracks and a master MAC that ties these together into one bundle. Furthermore, the MAC list contains a header that ties the MAC list to a specific "generation" of a specific medium. The generation is increased every time the DRM info changes. The final authentication is done by combining checksums of the medium-specific and the track-specific parts into a master "integrity check value" (ICV) which is stored outside of the FAT file system and only accessible using authenticated and encrypted SCSI commands.

The contents of "mclist01.hma" are mostly zero until DRM protected tracks are uploaded, the non-zero part looks like this:

0000000: 4d4c 5354 0000 0124 0000 0000 0000 0000  MLST...$........
0000010: 32af 72b6 0a4f 1612 e490 ce90 90b2 07ec  2.r..O..........
0000020: 0000 0001 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0001 0012 0000 0000  ................
0000040: 0202 0000 0200 0102 a36e 0000 caef 24f1  .........n....$.
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: fdd5 d64b 046f 53cf 4853 312d 8091 82ab  ...K.oS.HS1-....

The MAC list file is divided into three parts. The first 16 bytes are the file header, the next 80 bytes are for disc authentication and the remaining part is for track authentication. Both authentication parts start with an encrypted 3DES key used for authentication, followed by the data to authenticate. To decrypt the authentication key, a master key needs to be used. In the Sony DRM system, these master keys are stored in EKBs, in encrypted form. The disc authentication header contains an indication which EKB (that also means which master key) to use.

0000 BYTES  magic signature "MLST"
0004 DWORD  unknown purpose
0008 BYTES  8 unknown bytes, always zero, maybe padding.

0010 BYTES  16 bytes encrypted 3DES key for authenticating the first MAC list part
0020 DWORD  Generation number of the DRM info
0024 BYTES  20 unknown bytes, always zero, maybe padding
0038 DWORD  ID of the EKB used for decrypting the authentication keys
003C DWORD  4 unknown bytes, always zero, maybe padding
0040 BYTES  16 bytes disc ID. This is a copy of the real disc ID stored outside of the file system
0050 BYTES  16 unknown bytes, always zero, maybe padding

0060 BYTES  16 bytes encrypted 3DES key for authenticating the second MAC list part
0070 BYTES  4000 * 8 bytes MAC values of tracks. Intersting count, as Hi-MD only has 2048 tracks.

The file 00010012.hma

This file contains the "EKB", the enabling key block #00010012. This is the standard key block for HiMD audio. It's the string "EKB" followed by 29 null bytes (making a 32 byte header), and then the contents of the EKB that is also provided in OpenMG as 00010012-umd.EKB. It should never change, but if encrypted payware audio with other EKBs are uploaded, further all-numeric .hma files might appear.

The Audio Data File

The audio data file contains the raw audio data.

It is divided into 16k blocks of the following layout

0000 DWORD  Block Type ("LPCM" for PCM,"A3D " for ATRAC3, "ATX " for ATRAC3+, "SMPA" for MPEG)
0004 WORD   Number of frames (MP3 blocks only, PCM/Atrac blocks have fixed size)
0006 WORD   "MCode"
0008 WORD   Data size in bytes (MP3 blocks only)
000A WORD   Reserved
000C DWORD  Serial number of block in stream
0010 BYTES  PCM/Atrac: Encrypted DES key for the audio data
0018 BYTES  PCM/Atrac: DES CBC initialization vector for the audio data

0020 BYTES  up to 3FC0 of encrypted audio data (ATRAC never uses all 3FC0 bytes)

3FE0 BYTES  Backup of encrypted key (offset 0010)
3FE8 BYTES  8 bytes reserved
3FF0 DWORD  backup of Block Type
3FF4 WORD   reserved
3FF6 WORD   backup of "MCode"
3FF8 DWORD  low order 32 bits of the Content ID
3FFC DWORD  backup of serial number

In case of MP3 audio, the data is XOR encrypted. The key for encryption is created from the DiscID which read/written using special SCSI commands. In case of ATRAC/PCM audio, the data is DES CBC encrypted. See below for more info on encryption. Each audio block contains only complete frames. The space in the audio block after the last complete frame is unused - which is especially wasteful for 352kbit/s ATRAC3+, as the frame size is exactly 2K, so 1984 bytes per frame are ignored, i.e. 12% of the block size.

The _MDHIFI.HMA File

This file is obviously a backup-file for the directory content:

root@znote2:..disk/HMDHIFI> strings _MDHIFI.HMA 
.          
!0!0
..         
!0!0
TRKIDX01HMA 
!0!0
ATDATA01HMA 
!0!0
MCLIST01HMA 
!0!0
00010012HMA 
!0!0
_MDHIFI HMA 
!0!0
_RKIDX01HMA 
!0!0
_CLIST01HMA 
!0!0
_0010012HMA 
!0!0
root@znote2:..disk/HMDHIFI>

The Track-Index File

The Track Index File (or TIF for short, trkidxXX.hma) contains a TOC like data structure telling about differnt groups/tracks/parts of the music, which is contained in the audio data file (atdataXX.hma). The size of the index file is fixed 320K; it has the following structure (derived from symbol infos in the MAC software)

00000..00100 Header (256 Bytes)
00100..01100 Play order table (4K)
01100..02100 Programmed play order table (4K)
02100..02900 Group info table (2K)
02900..08000 Padding
08000..30000 Track info table (160K)
30000..40000 Part info table (64K)
40000..50000 Name table (64K)

The Header

0000 DWORD  Magic number to identify the Track index file "TIF " (54 49 46 20)
0004 WORD   Version number (seen as 01 00, i.e. 1 in little endian)
0006 WORD   "MCode" ??? (seen as 01 24)
0008 DWORD  reserved
000C DWORD  revision (seen as 00 00 00 01, i.e. 1 in big endian)
0010 DWORD  "GrpThmRevision"
0014 DWORD  "TrkThmRevision"
0018 DWORD  "GrpTxtRevision"
001C DWORD  "TrkTxtRevision"
0020..0100  reserved

All quoted field names have been directly taken from RTTI in the MacOS software. All revision fields were observed as zero.

As long as no endianess is specified, big endian is used.

The Play Order Table

Is an array of 2048 16 bit words. The first word is the number of tracks on the MD, the next words is the order in which the tracks should be played. A one track MD has the first and second word 1.

The Programmed Play Order Table

Is also an array of 2048 16 bit words. It is completely empty on a simple one-track MD.

The Group Info Table

Contains 256 group descriptors of the following layout

0000 WORD From
0002 WORD To
0004 WORD Name (string index)
0006 WORD Fringe

The group table on the one-track MD is completly empty (everything zero)

The Track Info Table

Contains 2048 track descriptors of the following layout

0000 DWORD   - date of recording (FAT format, 16 bit date, 16 bit time of day)
0004 DWORD   ! "EkbVersion" (Mac MP3: 0, Mac WAV: 10012; upload requirement: == 10012)
0008 WORD    - Title (string number)
000A WORD    - Artist (string number)
000C WORD    - Album (string number)
000E BYTE    - Track number (within Album, not on MD)
000F BYTE    - "Mode"
0010 8 BYTES ! MgrCK (upload requirement: completely zero)
0018 8 BYTES   CMac
0020 BYTE    - CodecId (see below)
0021 3 BYTES - Codec specific info
0024 WORD    - Part Number (index into Parts Info Table)
0026 WORD    - Track Number
0028 WORD    + Total time (units of seconds)
002A BYTE    + "Lt" (Mac MP3: 10, Mac WAV: 1; upload requirement: == 1)
002B BYTE    + "Dest" (upload requirement: == 1)
002C WORD    + More codec specific info
002E WORD    + reserved
0030 20 BYTE + Content ID (for Mac Transferred Data: 02 03 00 00 + 16 random bytes)
0044 DWORD   + Start of playback license validity (FAT format, or 0 for no restriction)
0048 DWORD   + End of playback license validity (FAT format, or 0 for no restriction)
004C BYTE    + "Xcc" (Mac MP3/WAV: 01; upload requirement: == 03 || == 07)
004D BYTE    + "Ct" 
004E BYTE    + "Cc" (Mac MP3: 40, Mac WAV: 44; upload requirement: == 08 || == 48)
004F BYTE    + "Cn" (Mac MP3: 00, Mac WAV: 3)

The +/-/! means: "+" this field is included in MAC calculation. "-" this field does not influence the MAC. "!" this field controls the MAC calculation

"upload requirement" means that the HiMD Transfer Tool for Mac checks the given condition before allowing an upload of a track to the PC. These checks are independent from the track format. "Mac MP3"/"Mac WAV" means that these values are set by the HiMD transfer tool if downloading that type of music. Probably the fields annotated that way are involved in copy controlling. The first entry in the track info table is a dummy entry that contains the number of the first free track in its Track number field. All free entries are chained using that field.

Codec IDs (Hex):

00: ATRAC3
01: ATRAC3+ or MPEG
80: LPCM

Codec specific info for ATRAC3

0021 Bit 1: Set for joint stereo (LP4)
0022 Bit 7-5: Sample rate
- 00: 32kHz
- 20: 44.1kHz
- 40: 48kHz
- 60: 88.2kHz
- 80: 96kHz
0023 Bit 5-0: Frame size in 8 bytes units
- 18: (Frame size 192 bytes) 66 kbit/s (LP4)
- 26: (Frame size 304 bytes) 105 kbit/s
- 30: (Frame size 384 bytes) 132 kbit/s (LP2)

Codec specific info for ATRAC3+

0022 Bit 7-5: Sample rate (like ATRAC3)
- 00: 32kHz
- 20: 44.1kHz
- 40: 48kHz
- 60: 88.2kHz
- 80: 96kHz
0022 Bit 4-2: Number of Channels
- 04: Mono
- 08: Stereo
0023 Frame size in 8 bytes units (-1)
- 17: (Frame size 192 bytes) 32 kbit/s
- 22: (Frame size 280 bytes) 48 kbit/s
- 2E: (Frame size 376 bytes) 64 kbit/s (Hi-LP)
- 8B: (Frame size 1120 bytes) 192 kbit/s
- B9: (Frame size 1488 bytes) 256 kbit/s (Hi-SP)
- FF: (Frame size 2048 bytes) 352 kbit/s

Codec specific info for MPEG

0021 constant 03, used to identify MPEG audio
0022 unused, zero
0023 bit field
- 80: Always set
- 40: Variable MPEG version (tracks with this bit set cause "cannot play")
- 20: Variable MPEG Layer (tracks with this bit set cause "cannot play")
- 10: Variable bitrate
- 08: Variable sample rate
- 04: Variable channel mode (Joint stereo/split stereo)
- 02: Variable preemphasis
- 01: Always cleared
002C: Bit field:
- C0: MPEG version (C0 = MPEG1, 80 = MPEG2, 00 = MPEG2.5, as in MPEG spec)
- 30: MPEG layer (encoded as in MPEG stream)
- 0F: Bitrate number (see MPEG spec)
002D: Bit field:
- C0: Sample rate from header (see MPEG spec)
- 30: Channel mode (00 = split stereo; 10 = joint stereo; 20 = 2*mono; 30 = mono)
- 0C: Preemphasis (see MPEG spec)
- 02, 01: always cleared.

The Part Info Table

Is an array of 4096 part descriptors:

0000 8 BYTES "PartKey"
0008 WORD    first block number in ADF for this part
000A WORD    last block number in ADF for this part
000C BYTE    number of first frame in first block for this part
000D BYTE    number of last frame in last block of this part
000E WORD    link to next part info for this part

Like in the track info table, the first entry contains the number of the first free entry in its link field. Each free entry contains the number of the next free entry in its link field (or zero at the end of the chain)

ADF blocks are 16KB. Thus the maximum adressable size is 1GB (16 bit block numbers)

The String Table

Contains 4096 string slots. Each string slot contains 14 bytes string data and a 2 byte link field. Free entries have the number of the next free slot in the link field; used entries have the number of the continuation in the low 12 bits and type info in the high four bits (8 = title; 9 = artist, A = album, C = disk or group name, 1 = continuation)

The first byte of the concatenated string of all the slots indicates the encoding (05 = Latin1, 84 = UTF16, 90 = ShiftJIS)

Differences between models - Sony MZ-NH700 and MZ-RH1

The last model released by Sony, the MZ-RH1, is suspected to use less encryption on recorded PCM-material. It has been observed that the key stored in the track entry (at offset 10, MgrCK) is all zeroes for the RH1-model whereas it is non-zero for older models (RH10 etc). The images md_with_one_pcm_nh700.img.gz and md_with_one_pcm_rh1.img.gz contain the same PCM-recording, but were transfered onto an MZ-NH700 and MZ-RH1 respectively. A check with md5sums shows which files are different, obviously the audio-data is *not* different, so the encryption must be the same. This means, that audio-data transfered with SonicStage onto the RH1 uses the strong encryption like the older models as well. The Sony-website for the Mac-Software, which we suspect to be able to upload less encrypted audio only, states: (1) An audio data transferred using SonicStage or MD Simple Burner, and an audio data downloaded from this software cannot be imported, which agrees with our observations.

MZ-NH700:

root@znote2:~> md5sum /mnt2/hmdhifi/*
64c228b7c4c1b02b6c2f1c11bc4148e6  /mnt2/hmdhifi/00010012.hma
5363c96604a0db55e0fafc787385e36b  /mnt2/hmdhifi/_0010012.hma
8c30a8e02a9f0cf0d3dbb43c570848d9  /mnt2/hmdhifi/atdata02.hma
925b99d01399fef20783fa1c9b666871  /mnt2/hmdhifi/mclist01.hma
924346a0e6b878561a92610be83f82ed  /mnt2/hmdhifi/mclist02.hma
4a90f43a7f8ede61f2e28ac844479468  /mnt2/hmdhifi/_mdhifi.hma
555584d9452203ad201b033c88ba6a6f  /mnt2/hmdhifi/trkidx01.hma
7e0c3645525530f05b06222e25fba164  /mnt2/hmdhifi/trkidx02.hma

MZ-RH1:

root@znote2:~> md5sum /mnt3/hmdhifi/*
64c228b7c4c1b02b6c2f1c11bc4148e6  /mnt3/hmdhifi/00010012.hma
5363c96604a0db55e0fafc787385e36b  /mnt3/hmdhifi/_0010012.hma
8c30a8e02a9f0cf0d3dbb43c570848d9  /mnt3/hmdhifi/atdata02.hma
114bc6cceff19adf8475753e576a53ac  /mnt3/hmdhifi/mclist01.hma
6700901c313c9bbfe2751ff3a26b600b  /mnt3/hmdhifi/mclist02.hma
b4a6398f6f908fa83031fc6ff66688aa  /mnt3/hmdhifi/_mdhifi.hma
fd7ae076d3a5116e6c478642d9007c81  /mnt3/hmdhifi/trkidx01.hma
f67cab3966a6f314099b37f9c8375494  /mnt3/hmdhifi/trkidx02.hma
root@znote2:~>

The following information courtesy Rene Rebe

File sizes on an empty disc:

-rwxr-xr-x  1 root root    172 Jul 23 11:07 himd-empty/hmdhifi/00010012.hma
-rwxr-xr-x  1 root root    172 Jul 23 11:07 himd-empty/hmdhifi/_0010012.hma
-rwxr-xr-x  1 root root  32768 Jul 23 11:07 himd-empty/hmdhifi/_clist01.hma
-rwxr-xr-x  1 root root  32768 Jul 23 11:07 himd-empty/hmdhifi/_mdhifi.hma
-rwxr-xr-x  1 root root 327680 Jul 23 11:07 himd-empty/hmdhifi/_rkidx01.hma
-rwxr-xr-x  1 root root      0 Jul 23 11:07 himd-empty/hmdhifi/atdata01.hma
-rwxr-xr-x  1 root root  32768 Jul 23 11:07 himd-empty/hmdhifi/mclist01.hma
-rwxr-xr-x  1 root root 327680 Jul 23 11:07 himd-empty/hmdhifi/trkidx01.hma

6x tracks:

-rwxr-xr-x  1 root root       172 Jul  2 00:08 00010012.hma
-rwxr-xr-x  1 root root       172 Jul  2 00:08 _0010012.hma
-rwxr-xr-x  1 root root     32768 Jul  2 00:08 _mdhifi.hma
-rwxr-xr-x  1 root root    327680 Jul 23  2006 _rkidx05.hma
-rwxr-xr-x  1 root root 360841216 Jul 23 15:37 atdata05.hma
-rwxr-xr-x  1 root root     32768 Jul 22 15:17 mclist04.hma
-rwxr-xr-x  1 root root     32768 Jul 22 15:22 mclist05.hma
-rwxr-xr-x  1 root root     65536 Jul  2 20:52 text_g01.hma
-rwxr-xr-x  1 root root    327680 Jul 23  2006 trkidx05.hm

Hexediting the Track meta data as well as abbritary positions
in the audio data does work (so they are not checksummed). That
is the player shows the updated meta data and still plays the audio.

The audio data is zero padded to 64k boundaries, that is a new
track added starts at:

002C FFF0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
002D 0000: 53 4D 50 41 00 27 00 03  3F 87 00 00 00 00 00 00  SMPA.'.. ?.......

Other data beside SMPA: PCM and ATX (seen on Atrac3+ encoded data on MZ-RH1).

SMPA appears to be 3des (tripple des) encrypted using one of the schemes:

plain, des ecb with session key, des cbc with session key

 Media Type name: audio
 Media subtype name: ATRACFAMILY
 profile: ATRAC, ATRAC3, ATRAC-X
 frameSampleSize: 512, 1024, 2048
 sampleRate: 32000, 44100, 48000, 88100, 96000
 frameLength: [license required]
 channels: 1, 2, 3, 4, 5, 6, 7, 8
 File extensions: at1, atr, at3, atx

Date and time encoding:

2006-07-24 : 09:14
0000 8050: 34 F8 49 C3 00 01 00 12  00 00 00 00 00 00 00 00  4.I..... ........
0000 8060: 00 00 00 00 00 00 00 00  49 74 E8 31 F5 C0 D0 AC  ........ It.1....
0000 8070: 80 06 28 07 00 01 00 01  00 0A 01 01 00 00 00 00  ..(..... ........
 0000 8080: 02 03 00 00 02 00 01 16  AF 49 00 00 03 8C 7F D9  ........ .I......
0000 8090: 26 4F D1 43 00 00 00 00  00 00 00 00 07 00 08 03  &O.C.... ........

2006-07-24 : 09:14
0000 80A0: 34 F8 49 DA 00 01 00 12  00 00 00 00 00 00 00 00  4.I..... ........
0000 80B0: 00 00 00 00 00 00 00 00  37 0F 59 2B DB 9E 50 E7  ........ 7.Y+..P.
0000 80C0: 01 00 28 2E 00 02 00 02  00 08 01 01 00 00 00 00  ..(..... ........
 0000 80D0: 02 03 00 00 02 00 01 16  AF 49 00 00 96 7D 33 3A  ........ .I...}3:
0000 80E0: 81 4F 34 59 00 00 00 00  00 00 00 00 07 00 08 03  .O4Y.... ........

2006-07-24 : 09:15
0000 80F0: 34 F8 49 FD 00 01 00 12  00 00 00 00 00 00 00 00  4.I..... ........
0000 8100: 00 00 00 00 00 00 00 00  A0 02 C7 B3 18 04 7E 51  ........ ......~Q
0000 8110: 01 00 28 B9 00 03 00 03  00 06 01 01 00 00 00 00  ..(..... ........
 0000 8120: 02 03 00 00 02 00 01 16  AF 49 00 00 D8 3D 73 50  ........ .I...=sP
0000 8130: BE D0 CE 7F 00 00 00 00  00 00 00 00 07 00 08 03  ........ ........


When a file is added:

Not touched:
0010012.hma
_0010012.hma
mclist01.hma
mclist02.hma
_rkidx02.hma

Removed:
_rkidx03.hma

Modified:

_hmhifi.hma:

  A lot of noise.

dc278fcb39eab5e97f5d1c5de1aadfc3  himd-current/hmdhifi/trkidx02.hma

8bca8235b1774769d437227a6be78dba  mnt/himd/hmdhifi/trkidx02.hma

atdata02.hma:

  Of course the whole data content. Just appended. Starting with "SMPA"

trkidx02.hma:

0000 0100: 00 01 00 01 00 00 00 00
0000 0100: 00 02 00 01 00 02 00 00

0000 8020: 00 00 00 00 00 00 00 02
0000 8020: 00 00 00 00 00 00 00 03

0000 80A0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
0000 80B0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
0000 80C0: 00 00 00 00 00 00 00 03  00 00 00 00 00 00 00 00  ........ ........
0000 80D0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
0000 80E0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........

0000 80A0: 2E 21 00 00 00 00 00 00  00 04 00 08 00 0A 01 00  .!...... ........
0000 80B0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ........ ........
0000 80C0: 01 03 00 84 00 02 00 02  01 22 10 01 D9 10 00 00  ........ ."......
0000 80D0: 01 0F 50 00 00 04 00 00  00 14 0E BD 96 C3 33 72  ..P..... ......3r
0000 80E0: B2 53 2B 68 00 00 00 00  00 00 00 00 01 00 40 00  .S+h.... ......@.

0003 0000: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 02  ........ ........
0003 0010: 00 00 00 00 00 00 00 00  00 00 00 B1 00 1F 00 00  ........ ........
0003 0020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 03  ........ ........

0003 0000: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 03  ........ ........
0003 0010: 00 00 00 00 00 00 00 00  00 00 00 B1 00 1F 00 00  ........ ........
0003 0020: 00 00 00 00 00 00 00 00  00 B4 01 D0 00 26 00 00  ........ .....&..

0004 0000: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 04  ........ ........

0004 0000: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 0C  ........ ........

And the meta info we already know how to decode:

0004 0040: 84 00 47 00 65 00 74 00  20 00 52 00 65 00 80 05  ..G.e.t.  .R.e...
0004 0050: 61 00 64 00 79 00 20 00  46 00 6F 00 72 00 10 06  a.d.y. . F.o.r...
0004 0060: 20 00 54 00 68 00 65 00  20 00 46 00 75 00 10 07   .T.h.e.  .F.u...
0004 0070: 74 00 75 00 72 00 65 00  00 00 00 00 00 00 10 00  t.u.r.e. ........
0004 0080: 84 00 54 00 65 00 6E 00  20 00 57 00 69 00 90 09  ..T.e.n.  .W.i...
0004 0090: 74 00 68 00 6F 00 75 00  74 00 20 00 50 00 10 00  t.h.o.u. t. .P...
0004 00A0: 84 00 28 00 44 00 65 00  6D 00 6F 00 20 00 A0 0B  ..(.D.e. m.o. ...
0004 00B0: 41 00 6C 00 62 00 75 00  6D 00 29 00 00 00 10 00  A.l.b.u. m.).....

Fragmentation

In order to implement download, we have to understand what happens when tracks are removed inbetween, e.g. have 3 tracks and delete #2. This creates a hole in the data-container.

The following screenshot illustrates a test with SonicStage and himdtest:

download 3 MP3s onto HiMD, show tracks with himdtest
delete MP3 #2, show tracks with himdtest
add another, larger MP3, show tracks with himdtest
download 3 MP3s onto HiMD, show tracks with himdtest
delete MP3 #2, show tracks with himdtest
add another, smaller MP3, show tracks with himdtest

Fragmentation of the FAT-Filesystem

After deleting track Nr. 2:

After downloading a new track after deletion of track 2:

During defrag:

Encryption

General picture

Red boxes indicate data stored on HiMD, Black boxes indicate "black boxes" - Operations we don't know how they work. For so called "weakly encrypted tracks" the Track key is 0000000000000000, the EKB ID is 00010012 and the fragment keys are 0000000000000000. This information fixes all input parameters to the Key encryption Key. This value is nearly known from analyzing the Mac software - it is F2266C6464C0D65C. As it is used as an DES key, the low bits of each bytes are unknown.

Fragment keys

Joining two tracks created on an RH10 (so not using zero-key-encryption) with an RH1 walkman (using zero-key-encryption) creates a result of two fragments employing fragment keys. Here are himdtest dumps before/after joining (track 47 is the first part and track 46 is the second part, yes, these numbers are backward, this has nothing to do with this experiment but with disorder of the free list from previous experiments); note the new content ID too:

Before join

  46: 0:07 AT3+ Unknown artist:Unknown title (Unknown album 0)
       0@06012 ..   6@06026 (0000000000000000)
     Content ID: 0203000002000102a36e0000a80d0fe3c9aeae71
     Key: 167960f39f024906 (EKB 00010012); MAC: 06f503a38982762b
  47: 0:07 AT3+ Unknown artist:Unknown title (Unknown album 0)
       0@05996 ..   0@06010 (0000000000000000)
     Content ID: 0203000002000102a36e0000d1ed2108778cad89
     Key: 5966e351a690c9f4 (EKB 00010012); MAC: f3c0f999f13d48e0

After join

  47: 0:13 AT3+ Unknown artist:Unknown title (Unknown album 0)
       0@05996 ..   0@06010 (437c871b58fe0a7e)
       0@06012 ..   6@06026 (b27b46d967e14fec)
     Content ID: 02030000020001171d9300005eab87d393f35e44
     Key: 0000000000000000 (EKB 00010012); MAC: 448b34515a6df04d

Links

http://www.marcnetsystem.co.uk/ - HiMD Lister, software that lists tracks on an HiMD
http://svn.exactcode.de/minidisc/trunk/main.cc - Program-code to parse HiMD meta data
http://forums.minidisc.org/index.php?showtopic=7944&hl= - Simple Hi-MD Music Structure Reader + Sources
http://forums.minidisc.org/lofiversion/index.php/t10877.html - the additional file "text_gXX.hma" from SonicStage 3.1
http://minidisc.org/hi-md_faq.html - HiMD FAQ from minidisc.org

DokuWiki

Table of Contents