You need the HR16B firmware because the HR16 firmware is wildly different. I believe there may be a suitable ROM image in there; if not I'll be able to turn one up for you.
In short (and this may be scribbled in the comments in the code somewhere) the sample names are some number of bytes long (can't remember, ten maybe?) and are plain ASCII. The samples themselves are not addressable by the CPU in any way. However, the sample playback ASIC is expecting a 16-bit value that represents the sample start pointer *shifted right by a nybble* - so basically you read the sample value from ROM, tack on a zero as the Least Significant Nybble, and that's you got your pointer. Simple.
Now the 0xff "ticks". You'll notice that the stock ROMs have samples that look like Christmas trees (strangely appropriate for the time of year). The valid sample data is -127 to 127, signed 8-bit. "But it says 16-bit on the lid, Gordon!" Yes, it does. It has 16 bits of dynamic range per sample but not 16 bits of resolution. So, when the sample is loud, it is described by 8 bits with a large jump in between, and when the sample is quiet it is described by 8 bits with a small jump in between. Great. Now we have -128, or 255, or 0xff left over, right? So use that as a marker.
Okay, here's the clever bit. Take your 8 bits of sample data and latch the D0-D7 from the ROM onto D8-D15 on your DAC - *through a kind of shift register thing*. Every time you see a single 0xff in the data, then it tells the shift register to "change gear" and shift the data, so after the first one D0-D7 from the ROM now maps to D7-D14 on the DAC - but the sample has been multiplied by 2 so it still fits the full range of values! Neat, eh?
Finally, more than one 0xff signals the end of the sample. You'll see all the samples finish with at least two 0xff if you open a ROM image with a sample editor.