Discussion
I ment this forum when saying "best platform". We may have lots of music file format descriptions, but however I didn't find a guide or a bunch of descriptions concentrating on how to detect them in memory (or statefiles), to rip them (calculating start adress and size) and to make them appear unplayed (deinitialization, sometimes needed to be played properly after saved).
However, I didn't use parts of your program BUT I used some of your descriptions and you and Laurent Clevy are mentioned in my program. I didn't release the latest version of my ripper (called AMoRE, once the aim of this project was to provide plain english ripping descriptions, which will hopefully now be done via this forum).
The project's mainpage can be found on
http://jmeister.cjb.net, you'll find a package with the ripper binary+sources and 7 ripping descriptions and a newer version as binary only without descriptions and sourcecode.
Now I put the latest sourcecode (44 file formats) online (just linked here, nowhere else to be found). It's located at
http://feltzkrone.freezope.org/ARV44.ZIP (142kb)
(case sensitive)
I will translate the sourcecodes (= ripping methods) to plain english text and then (that's what my "request" was) hopefully we'll be able to discuss and improve all those ripping methods here.
My aim was to find modules even if IDs like "M.K." (ProTracker) for example, were changed or removed.
Pro: possibility to find in such a way "protected" modules
Con: detection slowdown, more false alarms (and those are the reason why I cosider it as useful to discuss and improve the methods here)
About the sourcecodes
Each ripping unit provides two functions:
Mxxx_Detect(Address) returns TRUE if a module of the requested type is
detected
Mxxx_Save(Address,Filename) saves the found module
Functions which are used by each ripping unit:
DMPF_Byte, DMPF_Word, DMPF_LongInt stand for Dumpfile and Integer Type (big endian format => motorola format). The value requested from those adresses will be the result of these functions.
Apart from that I was using a MOD-Saver unit to convert MOD-Packer formats easily. The provided structs/functions are:
MOD_Struct => MOD header including sample headers, pattern order and signature
MOD_Note => one note record with subfields value, sample(number), effect and (effect)parameter
MOD_ClearHeader(MOD_Struct) => clears the mod header
MOD_SaveHeader(MOD_Struct) => saves the header
MOD_SaveNote(Pattern,Row,Channel,MOD_Note) => saves the note
The sampledata must be appended by the ripper unit itself.
Important: The sourcecode is for use with Turbo Pascal 7.0 as it interpretes lines from left to right unlike other compilers (VirtualPascal e.g.). A line like "NextContent+NextContent*256" may have to be changed to "NextContent*256+NextContent" when using a different compiler. Also, the sourcecode is for MS-DOS platform only, as VGA registers are involved. It looks ugly in Win2k/WinXP as color register changes are not done in a console window (unlike Win95/Win98, which do this). Even the default font is changed, so expect character crap when using it in a modern Windows version. Also AMoRE in this form has problems with long filename generation. Saving files does only work in Win95/Win98. When saving a file it will appear as "savefile.xxx" and not with the given name.
So I included a VirtualPascal-compiled win32 binary (amo_text.exe) for you to test its ripping accuracy (amo_000.pas up to amo_040.pas are included). Just the interface is changed. In amo_main.pas you'll find a list of which number stands for which music file format. The binary must be called with the filename of the savestate/memdump you want to scan, e.g. state1.uss (WinUAE, !uncompressed!) or chip.mem (WinFellow).
EDIT: @asle - Maybe we've talked before via e-mail. I think I reported one bug for one of your mod converters in an old PW4PC version and I also told you how to "unpack" the delta4-packed sampledata in the latest ThePlayer file versions.
.
.