Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_dumb (Read 310910 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

foo_dumb

Reply #525
Ugh, can't edit existing post, what's up with that?

Also, I don't mean to sound disrespectful but since experts hang out here I'll risk it and ask anyway - in your opinion which is really the most "balls-on accurate" module player for Windows - foo_dumb, XMPlay, OpenMPT or something else altogether? Certainly in terms of efficiency (loading speed etc.) I find the latter two to be way better than this plugin (again, sorry kode54), but I'm willing to trade that in for better rendition of the audio as close as possible to what the composer intended it to be like.

If you want "balls-on accurate", use the real players under an emulator like DOSBox (thought it does not emulate MMX instructions, which means it won't replay IT filters). The fact is that even if most module types are very similar in the effects they support, implementations always differs, especially in corner cases so kode54's current idea to have a separate "reverse engineered" player for each type of module is a good solution.

If you want an example of implementation divergence, the most spectacular would be the "Retrig an new note every X ticks" effect. As you are new to modules, it would be best to brush up on their basic working first but let just say for short that a tracker plays a sequence of rows specifying for each channel a note, an instrument and one or several effects affecting volume, panning, pitch, etc. Each row is maintained for a duration of S ticks, where S is a parameter called speed. Let suppose I specify a "Retrig every 3 ticks" this would mean triggering a new note on the 1st tick, the 4th, 7th, etc. Now suppose that I have 2 consecutive rows like this and the rows are played at speed 4. Notes are triggered at 1st and 4th tick of first row but what about the second row since 1st tick of second row follows just after 4th tick of first row? Well, every player has its own idea: MOD resets the "steps counter" every line so on the second line it is once again 1th and 4th row, S3M resets the counter only if the previous row didn't use a retrig effect (so in this case a note will be triggered on third tick of second row), IT never resets the counter, XM has a MOD like implementation and a different one for the effect which adds a volume change to each occurrence of the retrig. Another important matter is how do you count: do you count by increasing a counter (increase, if count reach target trigger note and reset counter) or by decreasing it (decrease, if count reaches 0 trigger not and reset counter)? In the first case specifying a different retrig step has an immediate effect because you compare the target against it, in the second case the new step takes only effect on the next retrig when the counter is reset. IIRC S3M and IT use the first case, XM and MDL the second one.

Basically, there is a tons of such differences or bugs (ex: FastTracker 2 always remains in sustain mode for panning envelopes, or sometimes jumps to the wrong line in the next pattern when you use the "pattern break" effect). For the technically minded, I would say that the most diverging popular types of modules to support are probably MDL and 669.

In the MDL case, it is the way sample frequency is handled. Most trackers handle this when the note is triggered. Say that the sample has 2x the frequency of the default MOD frequency: the note period is initialized with half its normal period. One could say this is correct but it also means that pitch slides or vibrato have more impact on the pitch. MDL does only take account of the sample's frequency at the mixing stage, so pitch slides are thus not affected by the sample's frequency which results in a very different behaviour from other trackers.

In the 669, the difference is even more fundamental: it does not use a period ("Amiga" mode) nor an semitone fraction ("linear" mode) as a way to regulate the note's pitch. For 669, the default note is given value 100, one octave above is 200, the next is 400; in other words pitch is expressed as a percentage of the default note's frequency, something which as far as I know is not supported by any of the referenced players. Note that this is not documented anywhere but is what I found out after playing with Composer 669 using DOSBox (it won't run unless you remove every memory manager, i.e. set ems, xms and umb to false in the DOSBox config).

foo_dumb

Reply #526
Thanks timber for that mini crash course in the complexities involved.  It's like emulating old games I suppose - not only do you have to recreate as best as possible all the features but also all the bugs and strange hardware/software quirks too. Considering how ancient many of the original trackers that created these proprietary formats are, haven't their sources been released yet? And didn't their authors document their formats properly? I'm surprised so much depends upon disassembly and reverse engineering, which no doubt has its limitations. I read recently that Jeffrey Lim plans to release the sources for Impulse Tracker soon to mark its 20th anniversary, which I think is a great idea and should hopefully make the job of developers like kode54 easier and help make modern players more accurate. BTW I think all the developers of these modern players are doing a really important job of data preservation, because it's not possible for everyone to go around installing emulators/VMs, hunting down and installing all the original trackers and so on just to play back historical formats.

Also, I'm sure others have thought of this before but is there any technical reason that would make it impossible to create a modern standardized module format that all these others can be converted to without loss of information? Some way for a common format to encapsulate all those differences? I realize all those millions of files in all sorts of formats can't be magically wished away, but if such a format (and converter and player) were available we could convert our collections slowly and over time end up with a far better state of affairs. So is this a nonsensical pipe dream or just such a monumental task that no-one's dared to attempt it yet?

foo_dumb

Reply #527
Also, I'm sure others have thought of this before but is there any technical reason that would make it impossible to create a modern standardized module format that all these others can be converted to without loss of information? Some way for a common format to encapsulate all those differences? I realize all those millions of files in all sorts of formats can't be magically wished away, but if such a format (and converter and player) were available we could convert our collections slowly and over time end up with a far better state of affairs. So is this a nonsensical pipe dream or just such a monumental task that no-one's dared to attempt it yet?

In the past several players/converters have attempted to define their own super format with the idea to be able to save any supported module in that format which they can replay or convert back to another format. In practice I noticed that very often the conversion is buggy or incomplete and that it is best is to keep the original files, at least you are sure that you still have all the information.

Let also face it: MOD, S3M, XM, IT and the other formats supported by kode54's player are already fairly standardized. As you go back in time you will find that sound cards of that time could not play samples but sound generators which you parametrize to produce different sounds or which even just produce basic sawtooth/triangle/square waves. This means that old players defined what we call "synthetic" samples and of course each player had its own way to define them. I have recently looked at the source of something called IIRC Hively player because I noticed a lot of .hsc files on an ftp site and there a sample is defined has follow: durations for attack/decay/sustain/release, attack/sustain volume and a list of commands. Basically sound volume varies in time from 0 to attack volume, then decreases to its sustain value which is maintained for some time before the sound decreases to 0. The list of commands is something like: use sawtooth wave for duration x, switch to square waves for duration Y, etc. I remember another format "Art of Noise" which is some kind of hybrid: it uses samples but had command lists associated to the samples with the possibility to control volume, pitch, vibrato, loop on part of the list or even switch to another command list.

If you look at more recent stuff like MadTracker, you will start to see all kind of filter based effects on a channel basis: echo, reverb, delays, flange, distortion, equalizers and no documentation/formulas explaining to reproduce them (there are some sources on SourceForge in the case of MadTracker but they seem to be those of an old version), and VST plugins (i.e. the modern version of synthetic samples).

To summarize module formats can be summarized by "infinite variations in infinite combinations" (if I remember the Babylon 5 quote correctly).

foo_dumb

Reply #528
To summarize module formats can be summarized by "infinite variations in infinite combinations" (if I remember the Babylon 5 quote correctly).

Guess you're right, as long as we have (fairly) accurate modern players available for the original formats it might be better after all to retain them instead of converting and risking loss of information along the way.

BTW, that quote's not from B5. I believe you're referring to the Vulcan Kol-Ut-Shan/IDIC (Infinite Diversity in Infinite Combinations) from ST: TOS.


foo_dumb

Reply #529
  • This module is played fine with default foo_dumb routines, but sounds off with active playptmod/modplay option: sun rocket.xm
  • This module sounds off using foo_dumb default routines, but is played fine with active playptmod/modplay option: shinjuku nights.xm
  • foo_dumb does not load these modules due to the order list being empty, though each module contains one single playable pattern: drivin.s3m , voodaa.s3m , temp.s3m

foo_dumb

Reply #530
This module is played fine with default foo_dumb routines, but sounds off with active playptmod/modplay option: sun rocket.xm

Please describe exactly what sounds off, and please also compare with FT2.

This module sounds off using foo_dumb default routines, but is played fine with active playptmod/modplay option: shinjuku nights.xm

It sounds as if ft2play is doing its job, then. I can't always guarantee that DUMB will be perfect, and I'm not sure I want to go into it and rewrite the playback routines to be perfect, even with this convenient reverse engineering work.

foo_dumb does not load these modules due to the order list being empty, though each module contains one single playable pattern: drivin.s3m , voodaa.s3m , temp.s3m

And how should I deal with that? Change both DUMB and st3play to always assume a minimum of one order that references the only pattern in the file?

foo_dumb

Reply #531
Please describe exactly what sounds off, and please also compare with FT2.

The lead instrument played on channel 16 to 21 appears to be missing a slight hall, the default foo_dumb routine recreates this much better.

And how should I deal with that? Change both DUMB and st3play to always assume a minimum of one order that references the only pattern in the file?

"IF order = 0 AND pattern > 0 THEN set order = 1" seems to be a reasonable approach.

foo_dumb

Reply #532
I fixed the sun_rocket.xm problem in ft2play. It was because of some errors in a finetune calculation ported over from FT2. Now it's up to kode54 to add the changes to his ft2play integration in foo_dumb.dll.

deus-ex, it now sounds like this in ft2play: http://16-bits.org/etc/ft2play_v0_65__sun_rocket_xm.mp3

New ft2play version, v0.65 - http://16-bits.org/ft2play.zip | http://pastebin.com/VBzt8Bfk
foo_dumb.dll will soon be updated with the changes (I guess).

foo_dumb

Reply #533
I fixed the sun_rocket.xm problem in ft2play. It was because of some errors in a finetune calculation ported over from FT2. Now it's up to kode54 to add the changes to his ft2play integration in foo_dumb.dll.

Yes, the .mp3 example you provided sounds so much better compared to the previous state. Glad I was able to help further improving ft2play. Thank you.

foo_dumb

Reply #534
And foo_dumb was updated a while ago.


foo_dumb

Reply #536
8bitbubsy, is this something you can help with?
  • This module isn't played back corrrectly with active playptmod/modplay: orange.ft


foo_dumb

Reply #537
8bitbubsy, is this something you can help with?
  • This module isn't played back corrrectly with active playptmod/modplay: orange.ft

I don't really support >4ch MODs in playptmod, that is kode54's work. I have no idea what could be wrong.

foo_dumb

Reply #538
gang
i think i understand the wiki badly, i'm trying to add my replaygain infos within the mod, s3m... files and not "only" in the foobar database
is there a setting i could change ?
many thanks


foo_dumb

Reply #540
8bitbubsy, is this something you can help with?
  • This module isn't played back corrrectly with active playptmod/modplay: orange.ft

I don't really support >4ch MODs in playptmod, that is kode54's work. I have no idea what could be wrong.


If you'd describe the exact problem, I could look into it, but it may not be down to the >4ch support.

It appears to be an "8CHN" file, which is 8ch FastTracker II format. The only oddities with those would be 8 cells per pattern row, and the slightly different effects.

This xm module seems to be completly silent with playptmod/modplay:
http://modarchive.org/index.php?request=vi...mp;query=167825


I cannot reproduce this.

foo_dumb

Reply #541
If you'd describe the exact problem, I could look into it, but it may not be down to the >4ch support.

I'm afraid I can't point you to any specific details, I do not write modules myself so I can't tell what might actually causing the issue. Switching between foo_dumb and playptmod/modplay you can easily hear the different recreation, though. I'm really sorry to leave you empty handed here.

foo_dumb

Reply #542
I'm sorry, I'm deaf to the differences. Different panning? Is it because you can actually turn on different interpolation and volume ramping with DUMB?

foo_dumb

Reply #543
I'm sorry, I'm deaf to the differences. Different panning? Is it because you can actually turn on different interpolation and volume ramping with DUMB?

Hi Kode54, no problem. I hope the following can help you to understand what I'm referring to.
Both for foo_dumb default or foo_dumb playptmod I'm using the same settings.


Here is each a sample of the first 30 seconds of orange.mod, along with their visual representation of the waveform by foo_wave_seekbar.
Comparing the waveform images also reveals the different output quite nicely, especially note the first ~10 seconds of each waveform.


orange.mod - 30 sec - foo_dumb default.mp3


orange.mod - 30 sec - foo_dumb playptmod.mp3


foo_dumb

Reply #545
Please upload your foo_dumb.dll.cfg.



foo_dumb

Reply #548
Please upload your foo_dumb.dll.cfg.

I tried to delete the cfg and it seemed to fix the problem.
I saved the the problem cfg for investigation: foo_dumb.dll.cfg
...
I then rechecked the settings. Seems to be volume ramping, if it is set to "none" it will be silent.