hdsm subtype 4 uses extended length

[josephw]

Original issue 29 created by josephw on 2013-12-09T07:37:09.000Z:

What steps will reproduce the problem?

1. Invoke e.g. MoveMusic on a copy of the iTunes library
2. Java out of memory when hdsm subtype 4 is parsed
   3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
TITL latest version with the patch from http://code.google.com/p/titl/issues/detail?id=18
Environment: iTunes x64 11.1.3.8 on Windows 7 x64

Please provide any additional information below.

(originally posted at https://david.gyttja.com/2012/09/08/move-music-library-and-update-itunes-database/)

I managed to correct one parsing error due to incorrect parsing of the “hdsm” header.

It appears that you must always parse the first 16 bytes 4 by 4 (b0 = bytes 0-3, b1 = bytes 4-7 etc):
b0 = “hdsm” / “msdh” depending on “endianness”
b1 = length OR dummy
b2 = dummy OR length
b3 = hdsm_subtype

If subtype == “04 00 00 00″ (= decimal 4) then the header length is given in b2 instead of b1.

So far I identified the following hdsm_subtypes in my library file (I always mention the header type as well as the preceding header type in order to see if there’s some more informaiton in there):

$ grep "hdsm]\s[3]" parse_tlv.log
[???? > hdsm] 3 4 subtype = 10 00 00 00
[hdfm > hdsm] 3 4 subtype = 0C 00 00 00
[hohm > hdsm] 3 4 subtype = 09 00 00 00
[hohm > hdsm] 3 4 subtype = 0B 00 00 00
[hohm > hdsm] 3 4 subtype = 01 00 00 00
[hohm > hdsm] 3 4 subtype = 0D 00 00 00
[htlm > hdsm] 3 4 subtype = 14 00 00 00
[hohm > hdsm] 3 4 subtype = 02 00 00 00
[hptm > hdsm] 3 4 subtype = 0E 00 00 00
[hplm > hdsm] 3 4 subtype = 15 00 00 00
[hohm > hdsm] 3 4 subtype = 04 00 00 00
[hdsm > hdsm] 3 4 subtype = 0F 00 00 00

Please note that in my (i64) examples, the first byte in a 4-byte word is always the least significant byte. In my DumpTLV routines I rewrite the byte order to accommodate the existing decoding if available (eventually).