#146590 - melw - Thu Dec 06, 2007 2:42 pm
Just happened to notice this, perhaps some people over here will find it useful:
Protracker NDS replay by hitchhikr - "A protracker files (.mod) replay routine for Nintendo DS, it's a direct conversion from the original Amiga one so it's should be as accurate as possible, also it handles modules from 4 to 16 channels and it's very small."
#146625 - hitchhikr - Thu Dec 06, 2007 10:39 pm
I was about the post it around here but since you did...
I fixed a bug in it since i discovered that the defines provided within libnds aren't accurate enough for replays (they need a separate control for the channels' volume).
Notice that some modules, especially the ones with very small instruments (aka chiptunes), can't be replayed accurately on the nds unless they have samples which (repeat) lengths are multiple of 4 bytes.
#146631 - tepples - Fri Dec 07, 2007 12:48 am
| hitchhikr wrote: |
| Notice that some modules, especially the ones with very small instruments (aka chiptunes), can't be replayed accurately on the nds unless they have samples which (repeat) lengths are multiple of 4 bytes. |
Can't the loader just double the loop length?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#146682 - hitchhikr - Fri Dec 07, 2007 4:01 pm
I thought about that but it would mean to have the loops of each non-multiple of 4 bytes samples copied twice in memory and the structure of the module to be re-arranged (read: increasing it's size, which may not be possible).
I don't think it's worth the hassle, it'll be easier to fix the modules directly inside the tracker (or to compose them with this small limitation in mind).
#146705 - Michoko - Fri Dec 07, 2007 10:43 pm
Wow hitchhikr! Brilliant work!
Certainly one of the most accurate replays of "Cream of the earth" I ever heard since the Amiga times!
#149070 - Maple - Mon Jan 14, 2008 6:20 pm
| hitchhikr wrote: |
| Notice that some modules, especially the ones with very small instruments (aka chiptunes), can't be replayed accurately on the nds unless they have samples which (repeat) lengths are multiple of 4 bytes. |
Not knowing enough about the terminology (I'm just getting started in modtracker stuff myself), I'm not quite on the same page as you and tepples on the double-copy idea.
Assuming when you say "length" you mean sample length, could you not just tweak the sample or tracker-file (either using a tool or in the loader as tepples said) to pad the samples to the 4-byte boundary? I haven't experimented enough to see if this would add dead air in the sample. (I would guess that it would.) Yeah, this brings up the file-size problem you mentioned earlier.
Alternately, if by "length" you mean the number of repeats (i.e. how many repeats in a length of time), could you not break it down into multiples of 4 bytes? I would assume you'd have to chop off the remainder. This would be no better for < 4 bytes, but would at least make it closer to accurate for > 4 bytes. (I don't think this is what you mean, 4 bytes is an awfully large amount for number of repeats.)
| Quote: |
I thought about that but it would mean to have the loops of each non-multiple of 4 bytes samples copied twice in memory and the structure of the module to be re-arranged (read: increasing it's size, which may not be possible).
I don't think it's worth the hassle, it'll be easier to fix the modules directly inside the tracker (or to compose them with this small limitation in mind). |
Many folks out there would not have the patience to have to learn how a tracker program works or, if they did, might not want to have to go through the trouble of mangling every chiptune they wanted to use in their app. Hence a tool to convert bum .mods to usable ones would be useful.
Now I'm curious to know how DekuTree64 worked around this...
All that said, excellent work.
#149091 - eKid - Tue Jan 15, 2008 7:51 am
When I wrote my .mod player I also made a little tool to fix the samples.
http://ekid.nintendev.com/modfix.exe
It's a command-line tool. Basic usage is "modfix input.mod output.mod". The samples in the output will unrolled and padded until the loop points are correct.
#149143 - DekuTree64 - Wed Jan 16, 2008 12:12 am
| eKid wrote: |
| The samples in the output will unrolled and padded until the loop points are correct. |
Yeah, that's basically what I did (although I did it when loading in the game). First, add silent samples to the start to push the loop start point onto a 4 byte boundary. Then for short loops, unroll to 2 or 4 repetitions so they're 4 byte aligned. For long loops, poke in a couple interpolated samples to make them longer.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#149396 - hitchhikr - Sat Jan 19, 2008 3:47 pm
That'll make the files bigger than necessary, imho, also i did the replay with not done yet modules in mind, not older ones.
I think the ds needs a dedicated tool anyway,
not some clone or port of another tracker (assuming the psg as well as the rest of the ds capabilities had to be handled).
The tracker which seems to be the closest to the ds hardware in term of capabilities is screamtracker 3 (minus the 16 bits samples), fasttracker 2 and co. require software mixers to be fully functional.
#149397 - kusma - Sat Jan 19, 2008 3:55 pm
| hitchhikr wrote: |
| fasttracker 2 and co. require software mixers to be fully functional. |
Question is, does one need "fully functional" or just "good enough"?
#149403 - tepples - Sat Jan 19, 2008 7:46 pm
To elaborate on kusma's question: What does .xm fundamentally need that the DS hardware mixer can't do?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#149413 - Sunray - Sat Jan 19, 2008 9:46 pm
Loop start points greater than whats fit in 16 bits, maybe?
#149414 - kusma - Sat Jan 19, 2008 10:11 pm
Actually, what I meant was more like "why can't you just tell your musician about the limitations to avoid them". There's no point in ditching XM just because ping-pong looping isn't supported on the hardware; you could just avoid using tunes with ping-pong loops.
#149417 - tepples - Sat Jan 19, 2008 10:19 pm
| Sunray wrote: |
| Loop start points greater than whats fit in 16 bits, maybe? |
GBATEK says the 16-bit count in SOUNDxPNT is a count of 4-byte units. Each unit represents two 16-bit samples, four 8-bit samples, or eight ADPCM samples. Assuming that the waves in .xm are converted to ADPCM first, what combination of sampling rate and time would need a loop that starts more than 524,280 samples into the wave?
kusma is on the right track: As long as the composer is someone hired by the producer (and not the end user), we can define a subset of S3M and a subset of XM that covers enough to be useful to a composer. The same converter that converts music files to use a shared instrument bank and compresses waves using ADPCM would also warn the user about waves whose attack/decay is too long. So there isn't much of a problem unless your program lets the end users be composers, such as a generic music player app (e.g. DSOrganize) or a completely skinnable game (e.g. the PC version of Lockjaw).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#149459 - hitchhikr - Sun Jan 20, 2008 2:19 pm
| Quote: |
Actually, what I meant was more like "why can't you just tell your musician about the limitations to avoid them". There's no point in ditching XM just because ping-pong looping isn't supported on the hardware; you could just avoid using tunes with ping-pong loops.
|
Sure, but it would also limit the xm to 16 channels without the ability to use adpcm packed samples or mixing the psg output with samples.
Also i read somewhere that the ds is able to do surround (?) + the lengths or instruments envelopes may be tricky to fix automatically.
Maybe i'm wrong about that but i think Fasttracker 2 (embarrassing) modules format was designed for PCs which at that time already had more than 4 megs of ram, don't the patterns need to be depacked in memory before being replayed or something ?
I'm not sure that loops can be achieved with adpcm samples, can they ?
#149461 - tepples - Sun Jan 20, 2008 2:40 pm
| hitchhikr wrote: |
| Sure, but it would also limit the xm to 16 channels |
We have a 10-bit DAC and speakers with little response below 500 Hz. What would >16 channels do for the listener?
| Quote: |
| without the ability to use adpcm packed samples |
The DS supports (a different flavor of) ADPCM. Waves would just be decoded from XM packing and encoded to IMA packing at compile time.
| Quote: |
| or mixing the psg output with samples. |
If you don't change the duty cycle over the course of an instrument using an envelope, using the PSG on channels 8-13 is equivalent to looped waves of length 8, at no big loss to the file size. PSG on channels 14 and 15 is noise, which at 32767 samples might, so there may be a chance to special case that.
| Quote: |
| Maybe i'm wrong about that but i think Fasttracker 2 (embarrassing) modules format was designed for PCs which at that time already had more than 4 megs of ram, don't the patterns need to be depacked in memory before being replayed or something ? |
The ufmod docs state that a pattern in XM is a sequence of rows. It can be unpacked one row at a time.
| Quote: |
| I'm not sure that loops can be achieved with adpcm samples, can they ? |
DS ADPCM handles looping. When a channel gets to the loop point in an ADPCM-compressed wave, it saves the current scale factor and prediction so that it can reload them when looping back to that point.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#149463 - kusma - Sun Jan 20, 2008 2:50 pm
| hitchhikr wrote: |
Sure, but it would also limit the xm to 16 channels without the ability to use adpcm packed samples or mixing the psg output with samples.
Also i read somewhere that the ds is able to do surround (?) + the lengths or instruments envelopes may be tricky to fix automatically.
|
True, I don't think XM is the best possible format for the DS. Personally, I'd convert the modules before to get ADPCM compressed samples where possible.
| Quote: |
Maybe i'm wrong about that but i think Fasttracker 2 (embarrassing) modules format was designed for PCs which at that time already had more than 4 megs of ram, don't the patterns need to be depacked in memory before being replayed or something ?
|
I consider the pattern-compression part of XM to be one of the more pointless features, because of just that - it's very tricky/slow to read the pattern-data directly. I'd much prefer a compression scheme that allows you to unpack one row of pattern data at the time. We designed something like this for Pimpmobile, but never got around to implementing it. It should be relatively easy, though.
| Quote: |
I'm not sure that loops can be achieved with adpcm samples, can they ? |
Due to the required state kept for adpcm-decoding, I doubt so. GBATek suggest that it works, but I suspect that loop-start for ADPCM is restricted to the beginning of the sample.
#154407 - hitchhikr - Tue Apr 15, 2008 8:03 pm
As requested by someone called peter here in your forum, i updated the replay and added the ability to specify a song position via a command and also as starting position.
#164565 - sasq - Fri Nov 07, 2008 12:52 pm
It looks like the ARM7-part replaces the default arm7 code completely - how easy is it to get this replayer to play nice with other arm7-code (like WIFI) ?