Optimized Player 6.1 Playroutine 'p6107.lha'

[Asle]

E:\Amiga\UAE\Decrunch>P61AConv.exe Deadlock-Musicdisk-3.mod Deadlock-Musicdisk-3.p61a
P61AConv V0.1 Copyright(C) 2022 Hop
ERROR: Unable to determine file type for input file 'Deadlock-Musicdisk-3.p61a'

E:\Amiga\UAE\Decrunch>P61AConv.exe
P61AConv V0.1 Copyright(C) 2022 Hop
Usage: P61AConv [OPTIONS] <inputfile> <outputfile>

It is confusing - so, what's really input ?

---edit
Wait, you actually expect the output file to have the extension "p61" !. wow.
Anyway, the music linked here hangs the prog : http://janeway.exotica.org.uk/release.php?id=58387
Possibly due to unused patterns ?

[hop]

Thanks for testing!

Originally Posted by Asle

It is confusing - so, what's really input ?

Sorry about that. Copy-pasted error message. Fixed now - the tool now assumes that output file format should be P61A, even if doesn't start with 'p61.' 'p61a.' or end with '.p61' or '.p61a'

Originally Posted by Asle

Anyway, the music linked here hangs the prog : http://janeway.exotica.org.uk/release.php?id=58387
Possibly due to unused patterns ?

You're right. Unused patterns were not fully supported. Feature added in V0.2 (attached).

C:\temp>P61AConv.exe MOD.beyond_music P61.beyond_music
P61AConv V0.2 Copyright(C) 2022 Hop
Loading mod from file: MOD.beyond_music
Module loaded.
Converting mod to P61A...
Conversion succeeded
Wrote P61A to file: P61.beyond_music

Summary
=======

File size:
  Uncompressed: 432158 0x6981E bytes
  Compressed:   372258 0x5AE22 bytes
  Bytes saved:  59900 0xE9FC
  Compression ratio: 1.16
  Space saving: 13.9%

Metadata:
  Uncompressed: 1084 0x43C bytes
  Compressed:   473 0x1D9 bytes
  Bytes saved:  611 0x263
  Compression ratio: 2.29
  Space saving: 56.4%

Pattern data:
  Uncompressed: 38912 0x9800 bytes
  Compressed:   9689 0x25D9 bytes
  Bytes saved:  29223 0x7227
  Compression ratio: 4.02
  Space saving: 75.1%

Sample data:
  Uncompressed: 392162 0x5FBE2 bytes
  Compressed:   362096 0x58670 bytes
  Bytes saved:  30066 0x7572
  Compression ratio: 1.08
  Space saving: 7.7%

The file seems to play alright using P61Con on Amiga.

[hop]

In case this is of use to anyone, please find attached P61AConv.exe V0.3

This version generates identical binaries to the original P61Con on Amiga for the modules I've tested (mainly the ones from P6112.lha). It also generates the usecode.

Generating identical binaries wasn't really necessary but I wanted to make sure I hadn't missed any important features, and it was a fun process...

By debugging P61Con with mod.Dolphins-Dreamquest in WinUAE wrt to the original source code, at label 'eienaa', it can be seen that the length in bytes of the match 'bestreallength' is calculated incorrectly. This can be thought of as "scoring" the match. At the point it is calculated, the search end pos (in A0) has been advanced by the size of the last chunk *which did not match* (if another chunk actually followed). The code then proceeds to incorrectly and unconditionally subtract #3 saying "Taken up by dummy note,length and 8-bit offset", when the size of the last chunk could be anything between 1 and 6 bytes (1-3 control bytes + 0-3 compression bytes), or there might not actually have been a last chunk if it was end-of-stream.

In the case in hand for P61.Dolphins-Dreamquest Pattern 3 channel 0 row 00 the search string is "F3 23 07 F3 23 07" but the compressed pattern data search window starts with "F3 23 07 F3 23 07 F3 23 07 B2 39 C2 01" which is 3 identical chunks "F3 23 07" of length 3 followed by a chunk "B2 39 C2 01" of length 4. Because of the mistake in the algorithm the tool favours the match starting at 0x3 over the one starting at 0x0 because on the second iteration the search pointer has advanced by an extra byte.

There's also another minor off-by-two error when calculating the score. It always subtracts 1 if offset >= 256 but doesn't factor in the size of the compression chunk into the offset. This means that 16-bit jumps can be favoured over 8-bit jumps in some situations (I think).

Neither of these bugs are dangerous at all, they can just result in slightly different (and occasionally, fractionally larger) binaries.

I'll try to release the source for this when it's feature complete and converted to pure portable C. The current big missing feature is sample compression.