A new really fast MOD replayer

[pink^abyss]

I think the player is perfect for modules with low register data rate. For chiptunes (as you already mentioned) the size may grow quite a bit.
I tested 'LSPConvert.exe' with "zapped-out.mod" by 4Mat which grows from 18kb to 49kb, tho thats certainly an extreme testcase.

I wonder how high data rate amiga songs (not Protracker modules) could be stored efficently and played fast... if its possible at all

[Samurai_Crow]

Originally Posted by pink^abyss

I think the player is perfect for modules with low register data rate. For chiptunes (as you already mentioned) the size may grow quite a bit.

I tested 'LSPConvert.exe' with "zapped-out.mod" by 4Mat which grows from 18kb to 49kb, tho thats certainly an extreme testcase.



I wonder how high data rate amiga songs (not Protracker modules) could be stored efficently and played fast... if its possible at all

Hashing the collection of register writes voice by voice to eliminate duplicates might help but I'm not familiar with the new format. I just wrote a module compiler years ago that needs a rewrite.

[ross]

The parser for intricate modules with B/D commands could fail.
Leonard you have a PM

[no9]

Just leaving a praise for new developments in Amiga audio departament.

[khph_re]

So there was a thread about getting the Amiga to play higher quality, and another about mixing channels, and now this gem.

Will these be combined into new formats? Or are they incompatible with each other?

Sorry if it's a noob question, I'm not a coder.

[Thcm]

Originally Posted by pink^abyss

Great execution Leonard! As always, you win over any amiga coder in optimization

Inspired by LFT from C64 I tried the same a year ago with my Pretracker replayer but my data exploded. A 3 minute song took around 50kb of replayer data when the original song only had 7kb of pattern data, so i scrapped it

I'm using the same approach for my C64 Protracker replayer for about 10 years now. The replayer logic would simply take too much processing power. Mixing is expensive enough. I first started with simple RLE compression of period, offset, volume and sample trigger streams and the newest data format uses a simple LZ packer of interleaved rle streams which results in good compression and fast enough decompression one byte a time.

[Thcm]

Originally Posted by pink^abyss

I think the player is perfect for modules with low register data rate. For chiptunes (as you already mentioned) the size may grow quite a bit.
I tested 'LSPConvert.exe' with "zapped-out.mod" by 4Mat which grows from 18kb to 49kb, tho thats certainly an extreme testcase.

I wonder how high data rate amiga songs (not Protracker modules) could be stored efficently and played fast... if its possible at all

I tested the mod with my converter and it "packs" to 26kb, but I'm using only a 256 byte lz history buffer, which packs complicated songs not so well. Lots of period and volumes changes like slides, vibratoe etc. result in less compression. Simple mods like HYMN_TO_YEZZ.MOD compress down to 2kb.

[leonard]

Originally Posted by pink^abyss

I think the player is perfect for modules with low register data rate. For chiptunes (as you already mentioned) the size may grow quite a bit.
I tested 'LSPConvert.exe' with "zapped-out.mod" by 4Mat which grows from 18kb to 49kb, tho thats certainly an extreme testcase.

I wonder how high data rate amiga songs (not Protracker modules) could be stored efficiently and played fast... if its possible at all

you're right high register pressure makes .lsmusic file bigger in memory. I don't want to store any compressed form in memory because my goal is to have the fastest replay ( even decoding lz or lz4 takes time ). Anyway a lot of mods just keep the same size, and some of them are even shorter in LSP

However, I'm planning to xform .lsmusic a bit so it could be better compressed on the disk ( right now compression ratio is ok, but it could be better if I interleave & delta the byte streams.)

The player will require some more work at init time. So it won't reduce the memory usage at runtime, but it will help on floppy storage. ( important for floppy demos )

[xaind]

Apologies if I missed this - but is the source for LSPConvert.exe available somewhere?

[lesta_smsc]

Originally Posted by xaind

Apologies if I missed this - but is the source for LSPConvert.exe available somewhere?

https://github.com/arnaud-carre/LSPlayer

[Jobbo]

Originally Posted by lesta_smsc

https://github.com/arnaud-carre/LSPlayer

He's asking for the source to the converter. Which is not public afaik.

[Antiriad_UK]

Leonard, what format are the samples saved in? I'm thinking amigaklang type scenario where the samples have to be saved in exactly normal protracker format or the system falls apart (like with p61 which modifies the samples).

[leonard]

Originally Posted by Antiriad_UK

Leonard, what format are the samples saved in? I'm thinking amigaklang type scenario where the samples have to be saved in exactly normal protracker format or the system falls apart (like with p61 which modifies the samples).

you could use "-nosampleoptim" option with LSPConvert to keep the sample bank un-modified. ( so you can use amigaklang with this option )

[Antiriad_UK]

Originally Posted by leonard

you could use "-nosampleoptim" option with LSPConvert to keep the sample bank un-modified. ( so you can use amigaklang with this option )

That is wonderful. Thank you

[pink^abyss]

Originally Posted by Thcm

I tested the mod with my converter and it "packs" to 26kb, but I'm using only a 256 byte lz history buffer, which packs complicated songs not so well. Lots of period and volumes changes like slides, vibratoe etc. result in less compression. Simple mods like HYMN_TO_YEZZ.MOD compress down to 2kb.

Good work!


I ask myself if there aren't more clever methods possible, because its not random data but MUSIC! For instance, it would be possible to pack Volume and Pitch lossy (considering psychoacoustics). Pitch would need to be linearized of course before...

[Thcm]

Originally Posted by pink^abyss

Good work!


I ask myself if there aren't more clever methods possible, because its not random data but MUSIC! For instance, it would be possible to pack Volume and Pitch lossy (considering psychoacoustics). Pitch would need to be linearized of course before...

That's one thing I'm already doing. Reducing to 16 different volumes and 127 different periods. Normally you don't hear any big difference on the c64. I try to choose quite optimal values for periods and volumes depending on frequency and distances.

[leonard]

Originally Posted by pink^abyss

For instance, it would be possible to pack Volume and Pitch lossy (considering psychoacoustics). Pitch would need to be linearized of course before...

I didn't investigated so much in that direction because I wanted to be a full compatible protracker player ( so I want the exact same PAULA registers values than an official player).

But I did some test like having just a 256 periods table to fit in 8bits etc. Helps packing but it also needs some extra cycles to read back the table ( most of MODs are not using more than 256 different periods so it works )

[Keops/Equinox]

Excellent stuff as usual Leonard.

[leonard]

Originally Posted by ross

The parser for intricate modules with B/D commands could fail.
Leonard you have a PM

thanks for reporting! I fixed the parser. You can get fixed LSP v1.01 here:

https://www.pouet.net/prod.php?which=88177

[Galahad/FLT]

I think if you throw this at Hoffman, his vast range of mods that pretty use every single trick in the book, and most importantly, he would know which of those modules might be a good bunch of test cases.

Great work