Author Topic: MO3 encoder edge cases  (Read 6306 times)

saga

  • Posts: 2748
MO3 encoder edge cases
« on: 14 Mar '21 - 13:49 »
While experimenting with the MO3 compression ratio, I found two little edge cases in MO3.exe... The attached example file uses all possible 255 instruments, but instrument number 255 ends up as instrument 0 (i.e. no instrument) in the imported pattern data. In fact, XMPlay seems to have the exact same bug.
There is also another peculiarity in the "usage" column of the instruments. Each instrument should be used equally often, but starting from instrument 173 onwards, the usage number is 64 lower than with the previous instruments. Since XMPlay gives up trying to calculate the song length of this file (which should be just one long song with no subsongs, but it shows up as two subsongs), I guess it's related to that.

saga

  • Posts: 2748
Re: MO3 encoder edge cases
« Reply #1 on: 14 Mar '21 - 14:19 »
While I'm at it, I noticed another limitation probably coming from the early ModPlug times... It seems like MO3/XMPlay only reads the first 32 plugin slots. OpenMPT supports up to 250 plugins these days, with chunk IDs FX00...FX99 for the first 100 and F100...F249 for the rest. I've attached another example file using those slots.

Ian @ un4seen

  • Administrator
  • Posts: 26083
Re: MO3 encoder edge cases
« Reply #2 on: 15 Mar '21 - 17:29 »
While experimenting with the MO3 compression ratio, I found two little edge cases in MO3.exe... The attached example file uses all possible 255 instruments, but instrument number 255 ends up as instrument 0 (i.e. no instrument) in the imported pattern data. In fact, XMPlay seems to have the exact same bug.

Oops. The MO3 encoder hasn't been updated for the recent MOD code rearrangements yet, so can't post that right now, but here's an XMPlay update for you to check in the meantime:

   www.un4seen.com/stuff/xmplay.exe

Please let me know if you still see that problem, or any new IT/S3M pattern problems (as the pattern loader was modified).

There is also another peculiarity in the "usage" column of the instruments. Each instrument should be used equally often, but starting from instrument 173 onwards, the usage number is 64 lower than with the previous instruments. Since XMPlay gives up trying to calculate the song length of this file (which should be just one long song with no subsongs, but it shows up as two subsongs), I guess it's related to that.

XMPlay and the MO3 encoder currently stop scanning (and jumps to the next unseen order) after 5000 seconds, just in case it gets stuck in an undetected loop.

While I'm at it, I noticed another limitation probably coming from the early ModPlug times... It seems like MO3/XMPlay only reads the first 32 plugin slots. OpenMPT supports up to 250 plugins these days, with chunk IDs FX00...FX99 for the first 100 and F100...F249 for the rest. I've attached another example file using those slots.

Yep, only 32 FX slots are currently supported. The XMPlay update above should add support for the extra slots.

saga

  • Posts: 2748
Re: MO3 encoder edge cases
« Reply #3 on: 15 Mar '21 - 21:46 »
Thanks for the update. Guess I'll listen to a few more ITs than usual in the next few days then. ;D

Quote
XMPlay and the MO3 encoder currently stop scanning (and jumps to the next unseen order) after 5000 seconds, just in case it gets stuck in an undetected loop.
I know how difficult the whole loop detection business is, but maybe you could consider to not start the timer (and abort scanning) if no position jump or pattern loop commands were found in the module so far? This should be pretty safe as in that case there's no opportunity for getting stuck.

Ian @ un4seen

  • Administrator
  • Posts: 26083
Re: MO3 encoder edge cases
« Reply #4 on: 16 Mar '21 - 15:36 »
Yep, good idea. Can probably take it a step further and only abort if there's a pattern loop, as they're the tricky things. Here's a MO3 encoder update with that change (and yesterday's changes):

   www.un4seen.com/stuff/mo3.exe

Let me know if any of the problems are still there (or any new ones).

saga

  • Posts: 2748
Re: MO3 encoder edge cases
« Reply #5 on: 16 Mar '21 - 18:12 »
Thanks, so far everything seems fine with the update.

Ian @ un4seen

  • Administrator
  • Posts: 26083
Re: MO3 encoder edge cases
« Reply #6 on: 30 Mar '21 - 16:32 »
The update above introduced a bug resulting in corrupt MO3 files from non-instrument formats, ie. MOD/S3M/MTM. So here's another update to fix that:

   www.un4seen.com/stuff/mo3.exe

saga

  • Posts: 2748
Re: MO3 encoder edge cases
« Reply #7 on: 8 Apr '21 - 21:18 »
Recyling this thread for another small update... OpenMPT will introduce two new commands on the MPTM format in the next version (finetune commands for micro-tuning), which would show up as command 30 and 31 in the IT pattern data respectively. Could support for these commands be added to MO3/UNMO3?

Ian @ un4seen

  • Administrator
  • Posts: 26083
Re: MO3 encoder edge cases
« Reply #8 on: 9 Apr '21 - 17:13 »
Yep, I'll add those for the next updates.

saga

  • Posts: 2748
Re: MO3 encoder edge cases
« Reply #9 on: 30 Nov '21 - 16:28 »
Ping... :) Can I assume that those two commands would be commands 38 and 39 respectively in MO3? Then I could already support for them in OpenMPT without having to wait for the new MO3 encoder to be released.

Ian @ un4seen

  • Administrator
  • Posts: 26083
Re: MO3 encoder edge cases
« Reply #10 on: 1 Dec '21 - 12:42 »
Yep, those effects have been assigned to 38/39 (hex) in the MO3 pattern data. Here are MO3 and UNMO3 updates including support for them, for you to test with.

   www.un4seen.com/stuff/mo3.exe
   www.un4seen.com/stuff/unmo3.exe

Let me know if you encounter any problems.

saga

  • Posts: 2748
Re: MO3 encoder edge cases
« Reply #11 on: 1 Dec '21 - 18:41 »
Thanks, I can confirm that the conversion is working fine.