Quote:
Mmm.. I wonder what might happen if we also patched the 0000 0010 (0x1000) value to a larger number, and adjusted max_fid to compensate.. Peter?

Crikey. OK. What you'd have to do is observe that (0x00001000, 0x00007000) is the ninth and last in an array of (offset,size) pairs. The first four pairs correspond to bookmarks 0-3. "Bookmark Zero" is the saved playlist, and bookmarks 1-3 are the user-visible bookmarks.

As shipped, the four bookmarks are 512 sectors long each (256K bytes). If you were being devious, you could sacrifice one or two bookmarks to the greater good, and increase the size of Bookmark Zero. So the table starts like this:
(0x00000000, 0x00000200)
(0x00000200, 0x00000200)
(0x00000400, 0x00000200)
(0x00000600, 0x00000200)
and if you changed it to be, say
(0x00000000, 0x000003C0)
(0x000003C0, 0x000003C0)
(0x00000780, 0x00000040)
(0x000007C0, 0x00000040)
then both the saved playlist and Bookmark 1 would have much more space, but Bookmarks 2 and 3 could be used only for shortish running orders. Blah blah no guarantee that doesn't shag it royally etc. but it should work.

If you were being proper devious, and you had lots of room (say 0xBC42 sectors, like Paul), you could remap some at the end of the paritition, on the basis no-one has more than say A000 fids:
(0x00000000, 0x00000400)
(0x00000400, 0x00000400)
(0x0000B000, 0x00000400)
(0x0000B400, 0x00000400)
...
(0x00001000, 0x0000A000) (not AC42)

You shouldn't fiddle with or move the small, 16-sector allocations in the middle of the list:
(0x00000800, 0x00000010) and its friends.

Peter