View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000814||OpenMPT||File Format Support||public||2016-06-14 02:53||2016-06-14 17:38|
|Reporter||vilxdryad||Assigned To||Saga Musix|
|Product Version||OpenMPT 1.26.02.00 / libopenmpt 0.2-beta17 (upgrade first)|
|Target Version||OpenMPT 1.26.03.00 / libopenmpt 0.2-beta18 (upgrade first)||Fixed in Version||OpenMPT 1.26.03.00 / libopenmpt 0.2-beta18 (upgrade first)|
|Summary||0000814: 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:
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 http://battleofthebits.org/ , hit me up whatever you need; i am heedful to your response.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||yes|
|Tested code revision (in case you know it)|
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.
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.
In addition to the things manx said (which are all correct):
<blockquote>also, note the audio quality is way different;</blockquote>
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>
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.
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: http://battleofthebits.org/lyceum/View/Composer+669/#Playback%20Notes%20for%20Composer%20669%20modules
Thank you for your dedication put on openmpt and in your responses to the community, love.
<blockquote>every 669 user</blockquote>
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.
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
Your article still contains some inaccuracies, e.g.
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 https://buildbot.openmpt.org/builds/auto/libopenmpt-winold/ 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.
|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||View Revisions|
|2016-06-14 17:01||vilxdryad||Note Edited: 0002451||View Revisions|
|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 1.26.03.00 / libopenmpt 0.2-beta18 (upgrade first)|
|2016-06-14 17:38||Saga Musix||Target Version||=> OpenMPT 1.26.03.00 / libopenmpt 0.2-beta18 (upgrade first)|