Uuuh Bero, i feel right, da ModPlug sounds better than you!

[Poser]

Hm, to really compare the tracks fairly they must have the
same (normalized) volume and don't use any additional
equalizer/surround/bass expander/...

For me it's important, that all samples after the export
into a wav-file sounding the same like played alone
with the keyboard.

[BeRo]

Hm, to really compare the tracks fairly they must have the
same (normalized) volume and don't use any additional
equalizer/surround/bass expander/...

For me it's important, that all samples after the export
into a wav-file sounding the same like played alone
with the keyboard.

I have didn't use any additional equalizer/surround/bass expander/etc. It's the resampling algorithm. A normal 256-point SINC algorithm with a blackman exact window.

[Poser]

I have didn't use any additional equalizer/surround/bass expander/etc. It's the resampling algorithm.

I just said that to avoid wrong results (many users have change the player settings to their own needs).

This settings must be set to default (or off) to get clean results to compare.

Anyway we can't compare because the tracks have not the same volume...

Of course i can provide 3 version of the example tracks exported with ModPlug,
but i normalize them and convert them to MP3 128K (not OGG).

If i do the same with BeRoTracker and use your suggested settings THEN
we could compare it really. Unfortunately BeRoTracker don't run anymore
on my machine (crashes at start), so for my part i can't do nothing more.

Maybe you could export it first to .wav, then normalize it and save it to .mp3...

But we need no meaningless spectrum-screenshot but a really HEARABLE difference.

I saved my example track also with the worst settings in ModPlug and it still
sounds better than the BeRo-version.

[BeRo]

As a hint: In BRT works the filters like in Original ImpulseTracker and not like in ModPlug. You can find more details here:  http://dumb.sourceforge.net/index.php?page=docs&doc=modplug . Short: MPT uses an other filter algorithm  than BRT+Original IT. BeRoTracker is optimized in the IT mode for original ImpulseTracjkr replayer rules, and not for ModPlug replayer rules, that are a bit buggy. Here is a Abuse Test Kit: http://bero.freqvibez.net/BeRoTracker/ImpulseTrackerReplayerRulesAbuseTests/abuse.zip Play it in Original IT, BRT and MT. Oroginal IT and BRT plays all files right, but MPT has some problems on some files. The WAV files are from the Original ImpulseTracker (Mono WAV Writer). I hope this abuse test kit can help the MPT developer to fix the bugs.

[BeRo]

I saved my example track also with the worst settings in ModPlug and it still
sounds better than the BeRo-version.

Yes, it's maybe right, because your example track is maybe optimized for the modplug replayer rules & filter algorithm, and THIS is for a compare between MPT & BRT very unfair. Because the modplug replayer rules doesn't often match to 100% the original tracker rules, and the MPT filter algorithm isn't equal with the Original IT+BRT filter algorithm.

[Trustmaster]

Hey guys, let's make music, not war

State everything below is my IMNHO:

"The best software is software you know best of all" - someone told. In fact, 80% of success in music creation (design, programming, etc., etc., etc.) process depends on you, not on your tools. The reason I keep using OpenMPT is that I've been using it for years and I grow as it grows while it grows as I grow; I know every inch in it and how to use every its feature. I've really got used to its interface so I can do in it what I can't in other trackers (e.g. Renoise).

If you don't get the expected results in other programs it means that you've done everything right: you've tweaked your track for OpenMPT/BeRo/Something_Else (depending on your choice). For example, I tweak my tracks for OpenMPT so that I should spend hours and hours changing volumes, pannings, filters, other effects and params in order to get best results in other software.

I believe BeRoTracker has the best resampling engine ever. But on the other hand I believe that the best solution is an optimal solution. The most simple way to detect the optimality level is the "cost/quality" ratio. As for current BRT version, cost overcomes quality: cost means the great amount of runtime bugs and extremely high hardware requirements, quality means BRT quality (sorry, no more comments on BRT quality). In case of MPT, quality is not so high but its cost is much much lower, so that for me MPT quality overcomes cost. And don't forget that its the era of VST/VSTi, samples are getting less important than they used to before.

BRT bugs and licensing. I don't think it's FreePascal's fault as bugs are born in our heads, not in our tools. That's just a lack of debugging. We should thank Olivier for 2 things: 1) for doing lots of debugging himself so that original MPT is pretty stable - the reason for hundreds people around the world to continue using it, 2) for opening its source. There's just a short period between a bug in OpenMPT is detected and fixed. "Two heads are better than one" - not always true if those two heads are too tired of regular work whereas that one head is genius, but not in case of debugging. So, the measures that can be taken in order to make BRT more stable are: running a user-friendly bugtracking system, increasing number of developers in the team (or at least the number of betatesters). I haven't mentioned opening its source yet. I understand that BRT is a beRo's child. Better to say, its his son: so beRo wants his son to return some resources (money, power, fame) when it ("he") grows up. But... does BRT have commercial success? If you ask me about BRT as it currently is I answer "no". The audio market is too crowded, you know. And even best sampler in the world can't be enough for getting an army of customers. Sure you can improve BRT and implement tons and tons of features in it but the market doesn't stop. As for me, I'm all for 2 kinds of licensing: complete OpenSource (e.g. OpenMPT, Linux) and Double Licensing (e.g. MySQL, Qt). If I was beRo I would choose the second one: distributing open BRT with 2 licenses. First one is free for non-commercial use. Second one is commercial.

OFFTOPIC to beRo about FPC (Free Pascal). Have you informed the FPC team about your project? I think you should do it so that they post it in the news (as they've done for Pixel Image Editor) or somewhere else for FPC users to know "FPC - what you can do with it" and for your project to get more publicity. (Remark: I'm leading a project written in Free Pascal, so I'm a FPC programmer also). BTW, a funny fact: open MPT is written in commercial VCPP environment whereas close BRT is written in opensource FPC, don't you think there should be a change?

[Squirrel Havoc]

BTW, a funny fact: open MPT is written in commercial VCPP environment whereas close BRT is written in opensource FPC, don't you think there should be a change?

I was just thinking of that, the source is available for MPT. But I cant help the project as I only have the standard version of Visual C++ that doesnt support P4 ASM and the like. I think it should be changed to a free compiler (and yes, I've thought about doing it myself ), the more people there are that are able to work on it, the more people who will actually work on it.

[Trustmaster]

The reasonable open compiler for OpenMPT would be MinGW G++ port with Bloodshed Dev-Cpp IDE. The problem is that MPT code is tied into MFC, but recently I've read an article about porting MFC applications from VCPP to Dev-Cpp (unfortunately, it is in Russian, but anyways it shows that there is such a possibility).

[BeRo]

OFFTOPIC to beRo about FPC (Free Pascal). Have you informed the FPC team about your project? I think you should do it so that they post it in the news (as they've done for Pixel Image Editor) or somewhere else for FPC users to know "FPC - what you can do with it" and for your project to get more publicity. (Remark: I'm leading a project written in Free Pascal, so I'm a FPC programmer also). BTW, a funny fact: open MPT is written in commercial VCPP environment whereas close BRT is written in opensource FPC, don't you think there should be a change?

Yes,  I've informed some FPC coders about BeRoTracker,  because FPC compiles BeRoTracker only right if no high code optimzations are enabled (-O2 or higher else  BRT can't load/&save any XM/IT Tracks and has corrupted routines, where the code peephole optimizier messed these code parts up. FPC compiles BeRoTracker  only right, if -O1 or no code optimzation are enabled. I wanted to report this bug, but nobody was interested with their reason "The code snippets are too big, please reduce it to the substantia", but  how, because if I did do this, FPC compiles this right,  but then BRT would still be compiled incorrectly. Therefore the bug will remain in the FPC compiler until they accept big bug reports.

[Trustmaster]

Bugreporting is not the way of informing I mean

You know, your bug is very personal and there's a little chance they fix it through the standard bugtracking system. On the other hand you can't fix it yourself if you know the reason because you're not a compiler developer. So the only thing that comes to my head is to catch some FPC developer on IRC and make him interested in helping you. Sounds like "you should find a friend in FPC team", but it is the most reliable way in fact. Or you may still try to find out the reason itself, but it is a lot of time and a great chance of spending the time in vain. Another question is "do you really need -O2 and -O3 optimization"? I don't think it is significant enough to speed BRT up a lot (at least more than 5%). But maybe this statement isn't right as everything is concreet code-dependent.

[BeRo]

Bugreporting is not the way of informing I mean

You know, your bug is very personal and there's a little chance they fix it through the standard bugtracking system. On the other hand you can't fix it yourself if you know the reason because you're not a compiler developer. So the only thing that comes to my head is to catch some FPC developer on IRC and make him interested in helping you. Sounds like "you should find a friend in FPC team", but it is the most reliable way in fact. Or you may still try to find out the reason itself, but it is a lot of time and a great chance of spending the time in vain. Another question is "do you really need -O2 and -O3 optimization"? I don't think it is significant enough to speed BRT up a lot (at least more than 5%). But maybe this statement isn't right as everything is concreet code-dependent.

I'm also a compiler developer (BeRoScript ( http://bero.0ok.de/page/index.php?p=23 ), PHPPascal ( http://bero.0ok.de/page/index.php?p=32 ), The 0ok Assembler ( you can a IDE Video at http://bero.freqvibez.net/t0aide.avi ), BeRoPascal a objectpascal compiler where only the parser is done etc.)
I've only no time to work me into the FPC sources and search&fix the bug in the x86 code peephole optimizer, because the FPC sources are very big and to complex to understand in a short time, how the compiler internals are defined etc. Short: I've too many projects (and not only BeRoTracker) to fix it myself.

[Trustmaster]

About the same feelings. For example, there's a fantom bug in FPC Sockets on Win32 that we've been searching for for about half a year but it is still there. An extreme lack of time. Running lots of things at the same time also...

Thanks for the links. It will take time to analyze your stuff.

BTW, my FPC project is Pascal Server Pages. I think it might be interesting for you as  for a web developer and FPC programmer.

[Poser]

As a hint: In BRT works the filters like in Original ImpulseTracker and not like in ModPlug. (...) Play it in Original IT, BRT and MT. Oroginal IT and BRT plays all files right, but MPT has some problems on some files. The WAV files are from the Original ImpulseTracker (Mono WAV Writer). I hope this abuse test kit can help the MPT developer to fix the bugs.

It's not a good idea to fix those so-called "bugs" because we musicians don't want
that our songs sounding different after each new release of modplug...

Perhaps also those "bugs" are the own "sound-flair" of modplug...

[Relabsoluness]

"The best software is software you know best of all" - someone told. In fact, 80% of success in music creation (design, programming, etc., etc., etc.) process depends on you, not on your tools.

Good point. When things get focused on the sound quality, it can easily be forgotten how, in a way, irrelevant sound quality issues after all can be. Also sound quality issues are much more 'era dependent' - for example a 'good' rhythm can remain for ages, where as todays good sound quality will hardly be such in relatively near future.

BTW, a funny fact: open MPT is written in commercial VCPP environment whereas close BRT is written in opensource FPC, don't you think there should be a change?

Indeed it could be nice that OMPT would compile with dev-cpp(or some other free IDE), even though I must admit that in certain things it's almost a pleasure to use visual C++ compared to dev-cpp.

But I cant help the project as I only have the standard version of Visual C++ that doesnt support P4 ASM and the like.

You mean it needs some 'professional/enterprise' version to compile OMPT?

[Squirrel Havoc]

But I cant help the project as I only have the standard version of Visual C++ that doesnt support P4 ASM and the like.

You mean it needs some 'professional/enterprise' version to compile OMPT?

I think so, the processor pack requires pro or better, and i just have standard