Tracker module plugin for Picard

I have published the “MOD files” plugin that adds support for loading various music tracker module formats to Picard. The plugin is available from the official plugin repository, you can download and install it directly in Picard in Options > Plugins.

Loading and saving the track name (as title tag) is supported for most of the formats that support storing this information in the file. See the table below for details.

I tested this with some files from my collection and additional files in various formats from

Please use this with care and don’t forget to make backups!

Supported formats

The table below lists the supported formats. The columns “Supported tags” shows the internal tag names in Picard supported and the maximum length of these fields in parentheses.

Name Extensions Supported tags Text encoding
MOD .mod title (20) CP850
Extended Module .xm title (20)
encodedby (20)
ISO-8859-1 if encodedby is “OpenMPT”, otherwise CP850
Impulse Tracker .it title (26) CP850
Impulse Tracker (OpenMPT) .mptm title (26) ISO-8859-1
AHX .ahx title (unlimited) CP850
MED .med - -
MTM .mtm title (20) CP850
S3M .s3m title (20)
encodedby (8)
ULT .ult title (32) CP850
Composer 669 .669 comment (108) CP850
Oktalyzer .okt - -

Important notes

  • I tested this with quite a few files, but there can be some variation in the files depending on what software generated them. These formats originated most often from a specific implementation for a specific tracker software, but then both the formats and the original software got adapted by others. Let me know if some variation of the files listed above does not load for you.
  • The file formats have very limited support for metadata. Usually there is only a single field that can hold a name or title. As this is very limited in length (often around 20 characters length, see table above) mod file authors often got creative filling these fields.
  • When saving the tag content will get truncated to the maximum supported length.
  • Text encoding is not well defined for module files. Basically you should stick to ASCII. There are only very few examples of files that are not using ASCII. I did some testing with various tracker software and existing files set default encodings for the different formats that worked for these examples (see table). But you might encounter files with differently encoded metadata. If not specifically defined CP850 is being assumed, which seems to work well. I might add user preferences to change the encoding in a future update to the plugin. The plugin also uses Picard’s functionality to convert punctuation characters to ASCII if possible.
  • Calculation of playback duration is currently not implemented. This could be added in the future, but requires more extensive parsing of the various formats (including in some cases several different format versions).
  • File names and the contained metadata are usually considered part of the file, as the authors often took care of both. So if you have a collection of mod files you probably would not want to alter these. Maybe you’ll use Picard just for reading this information and maybe even for organizing the files in folders.

Is this plugin useful? Tell me!

If you use this plugin I would appreciate your feedback and comments below. If there is some interest I might extend this plugin with more options in the future.

If you report some issues with reading specific files or formats or if you want an additional format being supported please always provide some example file with which the issue can be reproduced. Otherwise I won’t be able to look into the reported issue.


Cool to see support for this! Dealing with the various non-UTF-8 encodings probably wasn’t fun.

I’ve been submitting assorted modules to MB lately, but I use ffmpeg to convert them to MP3s to make it easier for me to play them on various devices. I usually submit AcoustIDs from the MP3s, although I’m not sure how helpful that is. fpcalc looks like it also uses ffmpeg to read files, so I wonder if Picard can scan modules to match them to recordings…

Regarding the limited metadata support, I’ve noticed that a lot of module composers used instrument/sample names to store additional comments/credits/greets, but I’m not sure that it’d be a good idea for Picard to overwrite those. :slight_smile:

1 Like

The encoding themselves are not so much the problem. They are of course limited in displayable characters, but that’s something we already have with other tag formats and in the end the user just has to live with the fact that only a specific subset of characters can be used.

The main problem is that this is not defined at all. Essentially files use the encoding that is being used by the tracker software. And those tools either did not support anything outside the ASCII range or maybe used the system specific character set.

This results in very few files being available with non-ASCII characters in the titles. I had none, but found a few on (but not for all formats).

If you found one it is still guess work what encoding it uses. What I found was that either CP850 or maybe CP437 character sets seem to fit often. Both where commonly used on DOS / IBM PC. It also could be something different, e.g. the Amiga Character set (but that’s pretty similar to ISO-8859-1 aka LATIN1). Only definitive thing I found was that OpenMPT uses ISO-8859-1.

No, scanning is not possible. The files would need to be converted before passing them to fpcalc, fpcalc itself can’t handle modules. But just like you wrote before, I’m also unsure how valuable these AcoustIDs are. Will decoding the modules with ffmpeg sound exactly the same as when decoded with a different tool or will there be differences?

Yes, that was often made. But for one reading all the instruments needs much more sophisticated format support, and I also would be unsure how to represent those as simple tags inside Picard. Apart from that I’m also don’t think Picard should write those. If some would be read I’d rather show them as part of some extra information in the info dialog of a file. But currently plugins don’t have the ability to add information there. But the ability for plugins to provide their own info tab is something I’d like to see added to Picard.