RJDMC 1.55

[tepples]

For an illustration, have a look at how I handle samples in the source code to LJ65.

So you have to do it manually for each sample?
Wouldn't it be better to have samples padded to 64 bytes and use the trail as I suggested?

They are padded to 64 bytes (see .align). It's no more manual than manually specifying the addresses of the trail. If you mean something else, please quote the part of the source code that you're claiming is too manual.

[Wave]

For an illustration, have a look at how I handle samples in the source code to LJ65.

So you have to do it manually for each sample?
Wouldn't it be better to have samples padded to 64 bytes and use the trail as I suggested?

They are padded to 64 bytes (see .align). It's no more manual than manually specifying the addresses of the trail. If you mean something else, please quote the part of the source code that you're claiming is too manual.

Except the starting address, that would be set 1 time, length and freq would be outputted by the program.
The way I am saying you don't have to realign all samples if the first one changes it's size.

EDIT: on NESHLA is something like this:
#rom.org 0xC000
tostarStart:
#incbin "../../music/dmc/tostar.dmc"
byte tostarData[] = {lo((tostarStart - 0xC000)/64)}
#incbin "../../music/dmc/tostar.tra"
flipStart:
#incbin "../../music/dmc/flip.dmc"
byte flipData[] = {lo((flipStart - 0xC000)/64)}
#incbin "../../music/dmc/flip.tra"
etc...

[tepples]

Length would be computed from the starting address of the following sample minus the starting address of this sample. Frequency is manual, I admit, but due to the coarse frequency control, it can't easily be changed unless your converter program resamples the data. Music engines usually have to change the frequency anyway for something like a Sunsoft bass, SMB3 timpani, or a Dr. Mario/Hello Kitty World drum line. But perhaps we could combine these approaches. The converter would store the default frequency as part of a 15-byte footer, and the same reference to the $4013 value for sample n+1 would let the playback code look up sample n's precise length and default frequency.

[Wave]

Length would be computed from the starting address of the following sample minus the starting address of this sample. Frequency is manual, I admit, but due to the coarse frequency control, it can't easily be changed unless your converter program resamples the data. Music engines usually have to change the frequency anyway for something like a Sunsoft bass, SMB3 timpani, or a Dr. Mario/Hello Kitty World drum line. But perhaps we could combine these approaches. The converter would store the default frequency as part of a 15-byte footer, and the same reference to the $4013 value for sample n+1 would let the playback code look up sample n's precise length and default frequency.

That's the idea, store on the footer the original data. For "fixed rate" samples, for Drum or Bass, you could select the sample via code.

[RushJet1]

Bumping for updated file.

[RushJet1]

v1.53 released

[danielt2k8]

When I try to go to 4x86.com, it asks me if I'm interested in this domain. It also says that the related searches are [Mod note: Edited to remove SEO terms]

[bootmii]

The same goes for the FamiTracker website. It says "Avstängd webbplats". Please attach RJDMC because it's lost media now.

[freem]

Was only able to find v1.4 via Wayback Machine; attached it to this post. Hopefully someone comes across the later v1.53 version.

[RushJet1]

Updated the link in the first post

[RushJet1]

1.55 released