While XMODITS is designed for bulk extraction, it would be convenient to specify what kind of files it should rip.

Internally, if "Strict Loading" is checked, then it will only allow files with the supported extensions:

• it
• xm
• s3m
• mod
• umx
• mptm

With custom filtering, it will be possible for the end user to finely tune these values.

Additionally, there will also be more properties to filter by:

• Size - Only allow files if their binary size fits within a particular range, or if they go below/exceed a threshold.
• Date - Only allow files if their date of creation (or modification) lies within a specified range, or it was created before/after a date.

When filtering by filename, these properties will suffice:

• starts with
• ends with
• contains

Though, adding regex support can improve flexibility.

after finding a track that is smaller, even when uncompressed, it now flashes this message, sometimes not even showing it. i use git so maybe thats the problem but idk

so i just dumped 4600 modules to wav-samples, and realized all the loop-points are gone.
is there a way of using xmodits so that the loop-points are not lost? i'm trying to load the samples into ST3/IT2.

Currently, only the waveform and play cursor is rendered. It would be more insightful if we could also see a sample's loop points, and also play samples with looping.

Module in question: synthmat.zip

This MOD file was made in 1996. So it should narrow down the possibility of it being made with Ultimate SoundTracker?

Issue: Neither Schisim Tracker nor my program can properly access data from this module.

Looking at the binary structure from a hex editor shows it doesn't follow the ordinary Protracker Module format I'm familiar with.

However, VLC and Audacity can play this module fine (although vlc will show garbled text if you view the comments).

I'll do some more research and document my findings.

Perhaps, I've underestimated the complexity of the MOD format...

Self assigned issue so I won't forget.

Experimental builds can be found here: #28

The current implementation doesn't take into account the Fine Tune setting in MOD files, and so samples are extracted in the wrong/unintended octave.

It's worth nothing that I'm using schismtracker, a modern implementation of impulse tracker, for my .it file.

I used xmodits to export the audio files from the song "apoplexy.mod", as well as my "apoplexy-stereo.it" edit. The edit was created using the exact same instruments from the original .mod file. However, upon exporting these, the .it exports have a halved sample rate and are pitched down by an octave. I've attached a video that also shows this comparison.

I've also uploaded both files to Google Drive for analysis, as I assume the problem exists within the files themselves. This isn't a pressing issue, as I can get the original samples from the .mod file, but it's likely worth looking into.

If you've received this error, I am aware of this issue.

This error was created to mitigae an out of bounds panic. It will be removed once I've properly implemented XM sample ripping.

Please do not upload your module in question, I already have ~4500 XM files to test.

This happened on a subfolder "A" of the full modarchive torrent, and is reproducible on subsequent runs, but I can't identify the offending MOD (xm?) because of the crash.

Hi! This is unreal - I'm wondering if rather than exporting to WAV if it's possible to export to the original file format? This would be super useful in generating a usable samples folder from a bunch of MOD files, to load directly into ProTracker for example.

Originally posted by @ferro4prez in #22

As I plan on adding more platforms, this would consequently make the releases more convoluted.

Not everyone knows how to navigate GitHub, so creating a website should help.

I put an .xm into build-multi.sh but my .xm file is 1k mb, could that be the source of it?