Question about DMC channel sample size

[bleubleu]

Hey guys!

I am working on improving DPCM support in FamiStudio and I was re-reading the DMC channel doc and I have a question.

What do guys think was the reasoning behind samples start addresses being 64-bytes aligned, while having their size being 16x + 1 ?

That "+1" is really wrecking my brain.

Why always play that extra byte? Wouldn't it have made more sense to have sample sizes simply rounded to a nice 16-bytes? Seems like this forces to you add padding between samples in most situation. The only reason I can think of it being designed like this is that it opens up the possibility of having 1 byte samples.

Also, I can clearly see some in NSFs, where samples sizes were already a nice multiple of 64, that they are often located one after the other in memory, without any padding. So I guess nobody cared and just assume an extra byte would be played?

Thanks!

From the wiki:

Code: Select all

    $4012      AAAA.AAAA     Sample address (write)
    bits 7-0   AAAA.AAAA     Sample address = %11AAAAAA.AA000000 = $C000 + (A * 64)

    $4013      LLLL.LLLL     Sample length (write)
    bits 7-0   LLLL.LLLL     Sample length = %LLLL.LLLL0001 = (L * 16) + 1 bytes

-Mat

[Jarhmander]

Hey guys!

I am working on improving DPCM support in FamiStudio and I was re-reading the DMC channel doc and I have a question.

What do guys think was the reasoning behind samples start addresses being 64-bytes aligned, while having their size being 16x + 1 ?

That "+1" is really wrecking my brain.

Why always play that extra byte? Wouldn't it have made more sense to have sample sizes simply rounded to a nice 16-bytes? Seems like this forces to you add padding between samples in most situation. The only reason I can think of it being designed like this is that it opens up the possibility of having 1 byte samples.

Also, I can clearly see some in NSFs, where samples sizes were already a nice multiple of 64, that they are often located one after the other in memory, without any padding. So I guess nobody cared and just assume an extra byte would be played?

Thanks!

From the wiki:

Code: Select all

    $4012      AAAA.AAAA     Sample address (write)
    bits 7-0   AAAA.AAAA     Sample address = %11AAAAAA.AA000000 = $C000 + (A * 64)

    $4013      LLLL.LLLL     Sample length (write)
    bits 7-0   LLLL.LLLL     Sample length = %LLLL.LLLL0001 = (L * 16) + 1 bytes

-Mat

The accepted theory is that there's an off by one error in the hardware, and that's easily conceivable. That +1 in DPCM length isn't much noticeable, except if you use the looping feature of the channel.

It's even more apparent that it's an off by one error because when using the IRQ feature, that IRQ fires right at the beginning of the last (+1) sample. Meaning that it fires, but the channel is still playing its last sample.

[za909]

I personally suggest ignoring the extra byte, or changing every sample to start with a byte of $55 or $AA to completely remove any unwanted change to the DAC level. It's not really worth doing all that padding to work around a barely noticeable artifact like that, but that's just my take on it.

[bleubleu]

The accepted theory is that there's an off by one error in the hardware, and that's easily conceivable. That +1 in DPCM length isn't much noticeable, except if you use the looping feature of the channel.

That makes so much sense, by far the best explanation. Thanks!

I personally suggest ignoring the extra byte.

Yeah, i'm kind of heading that way. If it was good enough for most games, then i'll probably do the same.

Thanks guys!

-Mat

[stan423321]

The accepted theory is that there's an off by one error in the hardware, and that's easily conceivable. That +1 in DPCM length isn't much noticeable, except if you use the looping feature of the channel.

It's even more apparent that it's an off by one error because when using the IRQ feature, that IRQ fires right at the beginning of the last (+1) sample. Meaning that it fires, but the channel is still playing its last sample.

How is the latter part an error? If you want continuously decoded samples, firing the IRQ after the last sample stopped playing would be already too late, wouldn't it?

[rainwarrior]

I personally suggest ignoring the extra byte, or changing every sample to start with a byte of $55 or $AA to completely remove any unwanted change to the DAC level. It's not really worth doing all that padding to work around a barely noticeable artifact like that, but that's just my take on it.

Starting with $55 is the least noticeable way to do this compromise. A lot of games just assumed it was an even multiple of 16 and have a noticeable blip of noise at the end of all their samples. Even $55 has an audible and distinct tone to it, very much not silent, but definitely the least offending thing to use as fill. ($00 or $FF are similarly appropriate as a fill compromise, but they also end up displacing the counter.)

Personally I think the 15 bytes of padding is worthwhile to eliminate the whole problem, especially in a very musically-focused application, but it depends on how much that space matters to you, and the nature of the samples you're using. Given that most DPCM samples are a few hundred bytes anyway, an extra 15 might not be a terribly significant collateral.

[za909]

Starting with $55 is the least noticeable way to do this compromise. A lot of games just assumed it was an even multiple of 16 and have a noticeable blip of noise at the end of all their samples. Even $55 has an audible and distinct tone to it, very much not silent, but definitely the least offending thing to use as fill. ($00 or $FF are similarly appropriate as a fill compromise, but they also end up displacing the counter.)

Personally I think the 15 bytes of padding is worthwhile to eliminate the whole problem, especially in a very musically-focused application, but it depends on how much that space matters to you, and the nature of the samples you're using. Given that most DPCM samples are a few hundred bytes anyway, an extra 15 might not be a terribly significant collateral.

Just to clarify, as I've only implied this, but in my mind these samples are contiguous and exist as a "block" in the ROM without extra padding at all (always a multiple of 4 used in the length register except for the last sample in the "block" where it doesn't matter). So every sample bleeds one byte into the next sample, but if that next sample starts with $55 the effect should be negligible.