View Issue Details

IDProjectCategoryView StatusLast Update
0000814OpenMPTFile Format Supportpublic2016-06-14 17:38
Reportervilxdryad Assigned ToSaga Musix  
Status resolvedResolutionfixed 
Platformx86OSWindowsOS VersionXP
Product VersionOpenMPT / libopenmpt 0.2-beta17 (upgrade first) 
Target VersionOpenMPT / libopenmpt 0.2-beta18 (upgrade first)Fixed in VersionOpenMPT / libopenmpt 0.2-beta18 (upgrade first) 
Summary0000814: Open ModPlugTracker has bugs on .669 modules

hi, after a long research on this cryptic format i found out that there are several bugs when trying to open .669 files on openmpt and then comparing it to the one open in the former dedicated .669 tracker called Composer 669 on its final 1.3 version

the most noticeable ones are the volume, Composer 669 just allows to define a volume between 0-F on hexadecimal numeration, thing that differs from the max volume set posible of 64 on openmpt that equals to 3F on hexadecimal numeration, thing that is not posible on Composer 669 producing a way louder sound, and unexpected bugs while opening a module in Composer 669 with different volume set on a note that is saved on openmpt

other one to note is that it has a way different way to interpret an octave, for example; a c-2 note on composer 669 would be c-5 on openmpt, so bugs will happen if you open a module on composer 669 that has a note below the octave 3 saved with openmpt

here are images for comparision:

this is how the module To The Moon, by jdark_hebron looks on Composer 669, where it was composed:

and here is how the very same module looks on openmpt:

also, note the audio quality is way different; while composer 669 mixes and outputs tracks on 22hz openmpt can do in whatever hz the samples are, also note the volume differences on the renders i uploaded from the very same module on both trackers:

how does the 669 module To The Moon by jdark_hebron sounds in Composer 669:

and how does the very same module sounds on openmpt:

as you can see is a great difference in sounding and feel; so composers that did worked on the former dedicated tracker wont sound any similar from what they composed on openmpt

i wrote an entire article on battle of the bits specifying Composer 669 characteristics and pointing out that only Composer 669 should be used for playback because of this, you can read the article here and most objetively this part that mentions openmpt and a longer explanation of what i just light out here:

thanks for reading and for making what openmpt is nowadays, i really appreciate your work on this amazing tracker.

Steps To Reproduce

you can download the module i used for these tests here

To The Moon by jdark_hebreon:

and the DOS tracker, Composer 669 from here:

use DOSBox and disable XMS and EMS to make it work, otherwise it will say there is not enough memory; more detailed steps are described here by me:

Additional Information

i am often on IRC under the name of vilxdryad or vil_mp when on mobile phone under EsperNet, EFNet and freenode; also i actually am an active user on , hit me up whatever you need; i am heedful to your response.

TagsNo tags attached.
Has the bug occurred in previous versions?yes
Tested code revision (in case you know it)




2016-06-14 09:35

administrator   ~0002447

First off, OpenMPT can only import 669 files and not save them. This means that OpenMPT will convert them (on loading) to a format OpenMPT can actually internally handle and save (which is S3M in the case of 669). This in turn means that OpenMPT will convert all pattern commands and effect parameters to the range S3M uses. This explains why octaves and volumes are displayed differently from Composer 669.
I'm not sure what you are implying when you say "saving from OpenMPT and then opening in Composer 669". Can Composer 669 even open S3M files (I did not have time to check yet)? In any case, even if it can, compatibility in that direction would not be a goal of OpenMPT unless it had native 669 saving support (which it does not and is not planned to have).
Concerning the global volume of playback: Apparently 669 does not specify any global playback volume at all, thus it is just a totally arbitrary choice by any player or program as to how much gain it wants to apply. No bug here as far as I can see.
After normalizing your files, I can hear obvious differences in panning. As I'm not the expert on various file format importers in OpenMPT, so this one is for Sage Musix to judge when he finds time to do so.

In any case, could you, in the future, please refrain form badmouthing OpenMPT before actually reporting the problem to the OpenMPT developers (so that we could actually handle it) or before even asking why OpenMPT behaves the way it does.
Blaming OpenMPT before actually contacting the developers feels insulting and does not motivate us developers that much solving the problem.

Saga Musix

Saga Musix

2016-06-14 14:31

administrator   ~0002449

In addition to the things manx said (which are all correct):

  • Panning: Like many trackers of the time, Composer 669 uses full stereo separation, i.e. a channel can be either played fully left or fully right. This is extremely unpleasant to the ears, especially with headphones, hence OpenMPT uses a more narrow panning scheme. Most module players do the same (and rightfully so).
    I noticed that panning is inverted compared to DOSBox, but what OpenMPT does is correct according to the manual:
    <blockquote>A misc note, on the SBPro the music will be in stereo, channels 1,3,5, and 7 will be played on the left and channels 2,4,6, and 8 will be played on the right.</blockquote>
    This may very well be a result of the infamous stereo swapping issues with SoundBlaster cards, a DOSBox issue, or the documentation is wrong. I can check later on a real SoundBlaster but for now I will stick with the documentation. After all, whether the stereo spectrum is inverted is probably not really relevant to any 669 tunes.

  • Value display: Composer 669 cannot import any of the formats that OpenMPT can save (to the best of my knowledge), so as manx says your point about OpenMPT saving values "outside of Composer 669's range" is completely moot. And even if OpenMPT could save 669 files (which it can not and never will), then we could always filter out the out-of-range values.

  • Composer 669 is not quieter because its volumes go from 0 to 15 rather than 0 to 64, but simply because its mixing routines are rather quiet. However, it is not in my intention to mix 669 files quieter than any other module format just because the original tracker maybe did so. In fact, if you run Composer 669 with a SoundBlaster 1 config (i.e. mono playback), it will be just as loud as OpenMPT. Only in stereo mode it is quieter than OpenMPT.

<blockquote>also, note the audio quality is way different;</blockquote>
Yes, OpenMPT can obviously produce higher quality audio than a tracker from 1992, and it is not our intention to make it sound worse than it could. If you really are into lofi sound, set OpenMPT's output to 22 KHz, 8-Bit.

The only valid problem I see at the moment is that one of the effects used in your example module is not imported quite correctly; but that's just a minor issue and should be easily fixable. Everything else is as intended; If you want authentic Composer 669 feeling, then you will have to use Composer 669.

<blockquote> you can read the article here and most objetively this part that mentions openmtp </blockquote>
Pointing out that OpenMPT displays pattern data differently than Composer 669 is not really objective, it's just part of how OpenMPT (and any other tracker that imports non-native formats) works. What you wrote there will just confuse people, can you please remove it?

Saga Musix

Saga Musix

2016-06-14 16:40

administrator   ~0002450

Update: I dug a lot more into Composer 669 today and found quite a few quirks regarding any pattern commands that modify the channel frequency (e.g. portamento). Composer 669 does not use linear slides (like most oldskool trackers from that time), but unlike all other non-linear formats that OpenMPT supports, it uses frequencies rather than periods internally. For libopenmpt this won't be a problem to fix, but in OpenMPT, frequency slides will remain inaccurate due to the internal format conversion to S3M.



2016-06-14 16:44

reporter   ~0002451

Last edited: 2016-06-14 17:01

Before anything, thank you for your fast responses; to be blunt respecting that openmpt saves 669 files in s3m format, i just realized it when you point it out; all this time were changing the extention to 669 so that explain why Composer 669 could not handle it, for the other side; my intention for writing this was not to be mean at all; this is my favorite module tracker and so far i can state openmpt is actually the best module tracker; i can not badmouth about it at any means BUT just wanted to light out these details, most because battle of the bits is a chiptune competition site, so an accurate playback is a must to all musicians to ensure their work may have a fair vote, not to be mean to any openmpt developer; i know how hard your work is and a definitely admire it; i am not blaming you but warning to battle of the bits composers about the differences between both trackers.

Also thank to you both manx and Saga Musix for pointing out technical details BUT my point of writing said comparison on the article was to make every 669 user aware about the accuracy and sound differnces of how openmpt handles 669 modules that were made back then on Composer 669, and as Saga Musix stated on his Panning and Value display, yea; openmpt sounds a lot nicier, thing is that; just openmpt users will listen 669 in that way, even setting its output to 22 KHz in 8-bit mode; it sounds different that on Composer 669, and thus it sounds different from what the musician intended, this is why i wrote that article; even so, as you ask for i may delete it since you consider it an insult, as manx stated, for exchange i can just state; be aware of the playback differences on open modplugtracker. so a user can decide if prefer a nicier sound or the original that might sound, as Saga Musix stated; extremely unpleasant to the ears in one of its aspects; which in my humild opinion i prefer, because that way is how 669 modules where supposed to sound in the first place.

As for the effects, that would be awesome! i am looking forward to see it

all this said, i state that i were not trying to be mean at all, i just wanted to light out the differences so 669 enthusiasts could decide what to use knowing what they will get, after all; 669 is an obscure format that is barely a topic anymore so just a huge research could make someone actually tell so by oneself.

EDIT: i edited the article i wrote, this seems fine to me:

Thank you for your dedication put on openmpt and in your responses to the community, love.

Saga Musix

Saga Musix

2016-06-14 16:51

administrator   ~0002452

<blockquote>every 669 user</blockquote>
I hope you are aware that this number is about zero these days (unless you count people who listen to modules as "users"). People will of course still listen to existing 669 modules, but noone with a sane mind still uses Composer 669 to actually write music. As such, I think it is acceptable to listen to it in high fidelty with OpenMPT - I do not consider the exact mixing algorithm, mixing frequency and mixing bit depth an inherent feature of the format that needs to be emulated by OpenMPT. Surely it sounds different, but does it matter? 100% authenticity can always only be provided by the original program something was written it.

Of course the bugs I mentioned above will be fixed but I will definitely not change playback fidelity to approximate Composer 669's low-quality mixing routines.

PS: It's OpenMPT (ModPlug Tracker), not OpenMTP.



2016-06-14 17:03

reporter   ~0002453

i am aware of that lol, all this dedication i am giving at researching Composer 669 is for historical documentation purposes since as you said, the number of users of 669 modules is close to zero lol, yea; by users i mean people that listen and or composes in the 669 format, i find it completely acceptable you opt for so at playback quality; is a matter of taste so it can not be more right and my bad for the typo lol i fixed all of those already. Thank you a lot, Saga Musix and manx! = 3

Saga Musix

Saga Musix

2016-06-14 17:26

administrator   ~0002454

Your article still contains some inaccuracies, e.g.
<blockquote>The mixing and output is done at 22 kHZ in the *.669 file format.</blockquote>
As I said, the mixing frequency is not inherent to the file format itself. "Mixing is done at 22 kHz in Composer 669" would be correct. In fact, the only other 669 editor in existence, Unis 669, uses the Gravis Ultrasound, which can mix audio at 44 kHz. This is yet another reason to not add any specific mixing behaviour to OpenMPT for 669 modules - you never know if the file was intended to be played in Composer 669 or Unis 669. Please just remove this kind of information, it's not going to help anyone if you spread false facts like this one.

Saga Musix

Saga Musix

2016-06-14 17:38

administrator   ~0002455

r6502 introduces fixes to portamento and vibrato commands in 669 files, so they sound more or less identical to what Composer 669 does. Note that these fixes can only be made use of in libopenmpt, not OpenMPT itself. libopenmpt does not need to convert 669 modules to S3M internally, so it can play them back as intended.

To test the new behaviour, you can wait until r6502 is available at and then either use openmpt123 from that package to listen to 669 files, or use one of the provided input plugins for XMPlay, Winamp or foobar2000.
If you can find any other playback bugs in 669 files through openmpt123 or one of the input plugins, feel free to re-open this report.

Issue History

Date Modified Username Field Change
2016-06-14 02:53 vilxdryad New Issue
2016-06-14 09:35 manx Note Added: 0002447
2016-06-14 09:35 manx Assigned To => Saga Musix
2016-06-14 09:35 manx Status new => assigned
2016-06-14 09:37 manx Priority immediate => normal
2016-06-14 09:37 manx Severity major => minor
2016-06-14 09:37 manx Category Playback Compatibility => File Format Support
2016-06-14 14:31 Saga Musix Note Added: 0002449
2016-06-14 16:40 Saga Musix Note Added: 0002450
2016-06-14 16:44 vilxdryad Note Added: 0002451
2016-06-14 16:51 Saga Musix Note Added: 0002452
2016-06-14 17:01 vilxdryad Description Updated
2016-06-14 17:01 vilxdryad Note Edited: 0002451
2016-06-14 17:03 vilxdryad Note Added: 0002453
2016-06-14 17:26 Saga Musix Note Added: 0002454
2016-06-14 17:38 Saga Musix Note Added: 0002455
2016-06-14 17:38 Saga Musix Status assigned => resolved
2016-06-14 17:38 Saga Musix Resolution open => fixed
2016-06-14 17:38 Saga Musix Fixed in Version => OpenMPT / libopenmpt 0.2-beta18 (upgrade first)
2016-06-14 17:38 Saga Musix Target Version => OpenMPT / libopenmpt 0.2-beta18 (upgrade first)