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.

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?

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>
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.

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.
<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.

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.
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.