Amiga exotic players

[vtlmks]

I can't say I've tested everything, but I have ~40 replayers converted to C, and I've written two replayers that I have missed for quite a while, a real soundtracker replayer that don't use protracker effects (supports modules made in Ultimate Sound tracker by karsten obarski) so now rallyemaster.mod sounds correct, and the other modules that also used arpeggio but got some other weird effect insted..  and I made a player for Fashion Tracker, which has stopped one remake I wanted to do, so that demo might now be done

Enough blabbering, here is the repo:  https://github.com/vtlmks/amiga_exotic_players

I also include a zip file with a compiled testplayer that you can test various modules, I have only tested it in WINE on linux, but it should work on windows 7+ without any dependencies!

/Vtlmks

edit: updated the executable with the new one that doesn't trigger virustotal

[va!n]

@vtlmks:
Nice job! I’m actually also working on (or at least trying to build) a few tracker replayers myself (FC v1.0–v1.4, SA (including packed), and some others) in C/C++. However, these are not basing on C# to C/C++ ports.

Thanks for sharing. That said, I’m a bit confused about the .exe you provided… (see screenshot)

[vtlmks]

The source for the executable is in the repo:
amiga_exotic_players/test_player/test_player_win.c

The reason for the false positives is that the build was unusual. I was trying to make a single .exe with zero installed-runtime dependency, which led to a build profile that looks like the textbook "shape" of a packer or shellcode loader to heuristic AV engines. The "Gen:Variant.Lazy" family is specifically Bitdefender's structural heuristic, which a dozen other engines license, which is why the same pattern showed up under different names across so many vendors. The "!ml" suffix means machine-learning detection, not a signature match.

The main flags it hit:

CRT-free build with a custom mainCRTStartup entry, hand-rolled memset/memcpy/sin, etc. baked into the binary. Almost no legit Windows software does this.
Imports only kernel32, user32, winmm. A minimal import table is a known indicator for binaries that resolve APIs dynamically at runtime.
No VERSIONINFO resource, no application manifest, missing ASLR/DEP/NX bits.
Unsigned (the biggest factor long-term, but signing certs cost money).

Made a new executable (VirusTotal screenshot attached, now 0/71).

Its roughly twice the size, which is the cost of linking with the standard CRT:

Imports: KERNEL32.dll, msvcrt.dll, WINMM.dll. Three system DLLs, all present on every Windows since the 90s, no installed runtime needed.
DllCharacteristics: HIGH_ENTROPY_VA, DYNAMIC_BASE, NX_COMPAT (full ASLR/DEP/NX).
VS_VERSION_INFO block, embedded application manifest, normal int main() entry, recognizable CRT call shape in the code section.

Looks like a normal program now.

Code is pushed to the repo.

/vtlmks

[vtlmks]

@va!n

sorry, got a bit worried about my program being flagged so I got a bit tunnel vision going on and didn't reply to your message

I have looked for a Sonic Arranger player for a long time and never found one, nice there are more people that are interested in writing players, future composer has so many good songs as well.
I am considering writing a player that is mainly for exotic amiga modules, I know I can play them on xmplay with delix plugin, or audacious with the uade plugin, but I've always wanted to make a winamp like player, and I like that kind of look too..

/Vtlkms

[vtlmks]

@vain

Saw another message from you so I reply to that here since it's kinda related:

The "@OARV1" header is just a wrapper around an lh.library compressed SOARV1.0 module. lh.library is a 1990s Amiga compression library by Holger Burkhardt (LH algorithm, related to LHA but with its own header layout). Once you decompress the payload, what comes out is a normal SOARV1.0 module, so the rest of your existing loader/player handles it without changes.

For the decompression step itself, the easiest reference is NostalgicPlayer's C# source. The Sonic Arranger module-converter has the lh.library logic alongside the packed-format detection. Porting it gives you support for "@OARV1.0" plus any other Amiga module that ships through lh.library packing.

If you don't want to port the decompressor yourself, you can also pre-process the files offline with an Amiga lh.library tool and feed the unpacked SOARV1 to your player as-is, but doing it in-loader is the better long-term path since the same code unlocks lh-packed variants of other formats.

I haven't ported it myself yet either; my Sonic Arranger loader currently rejects "@OARV1.0" for the same reason you're stuck. It's on my TODO list, just not high priority since there are very few packed Sonic Arranger modules in the wild.

/vtlmks

[va!n]

@vtlmks:
Since I'm currently quite exhausted again due to health reasons, I'll keep it brief.

1) Thanks for the updated executable. I've only tested it with a few tracks in 14 different formats so far. It seems to be running under Windows 11.

2) "Face The Music" in particular doesn't seem to like some of the tunes; it always displays "no registered player recognized this file."

3) I didn't mean to discourage you with my feedback... You've done a truly fantastic job - and for that alone, you get karma++ from me.

4) Thanks also for your feedback and information regarding the packed SA files. ;-)

[vtlmks]

No worries, wasn't discouraged at all, I just wanted to be transparent about what triggered the heuristics. Glad it works on Win11!
I will dig into Face the Music, I didn't test each format extensively, so I likely missed some details.. possibly there is also some versioning issues.