foo_dumb, experimental new modplugin, by Kode54 Options

[kode54]

I haven't done anything about "Billie Jean", other than fix the pattern loop end causing the break to row effect to take place for every order thereafter. Now it only does it once. The fact that the first half of the second order of the song is skipped is due to a bug in FT2.

I did implement a new 65536x band-limited oversampling resampler in place of the original aliased / "none" interpolation mode. While it is a bit slower than cubic interpolation, it sounds much better than the original aliasing mode, which I assume most people would be using for chip tunes and not because their computers are too slow for cubic interpolation.

[deus-ex]

Hello Kode54,

I tested the new 65536x band-limited oversampling resampler with several Chip tunes.
Here are my findings so far:

• trail_of_tears.it : The bass starting with Order 03 on Channel 11 & 12 doesn't continue to play through the whole song but gets silent instead during Order 03.
  
• walking_with_the_stars.it : The following weird effect ONLY appears when starting up Foobar2000 to play walking_with_the_stars.it, no other module should have been played before. It's suffice to play just the first few notes of it and THEN playing trail_of_tears.it (see above). You should find that from Order 01 onwards when Channel 7 to 9 start to play, audible distortions appear. This does not happen with previous foo_dumb v0.9.9.22. Maybe an issue with some instrument/sample buffers?
  
• chestnet.it : Audible clipping through whole song which is not there with foo_dumb v0.9.9.22.
  
• methodyne.it : The bass drum starting with Order 03 on Channel 10 produces clipping which does not happen with foo_dumb v0.9.9.22.

My settings:



Overall most Chip tunes I checked do sound better now indeed, I think I just need to get used to the fact that with the new resampler more of the higher frequencies get filtered out which shouldn't have been audible anyway. I hope there's room for improvement of the new resampler to get rid of most of the clipping without breaking it's function. But nevertheless, thank you for the update, Kode54.

This post has been edited by deus-ex: Jan 11 2011, 13:14

[kode54]

• trail of tears (searching - chip version).it - Filename corrected. Oh, and this problem is due to misuse of the envelope carry effect. The envelope in question carries, and loops forever on a zero volume level. This can be fixed by editing the file, either to disable envelope carry, or more like XMPlay and OpenMPT, by disabling the envelope loop, which allows the envelope to reset once it has reached the end.
• walking_with_the_stars.it - I can only reproduce this some of the time, and I have no idea what causes it. In fact, sometimes, just listening to the above file completely will cause it, and for repeat plays as well. Then running a decoding speed test that decodes the above file sequentially 3 times seems to fix it again. No idea, as there don't seem to be any uninitialized variables in use anywhere.
• chestnet.it - Fixed.
• methodyne.it - 404. In fact, there doesn't seem to be a Blz directory in the impulsetracker directory at all.

Anyway, I updated it with what little I changed.

• Fixed aliased resampler loop conditions, removing useless division and count methods in place of fixed point clock position comparison. Fixes all of the clicking conditions above, except for the intermittent one in trail of tears.
• Removed resampler loop unrolling, as it actually made things slower, and bloated the binary size horribly.
• Fixed a bug with songs triggering notes on the first order with instrument changes before there are any actual notes. Fixes a stray bass note triggering at the start of walking with the stars.it.

Also, mudlord reported a looping issue with the module Necroscope by Mantronix/Razor 1911. I'm calling this a non-issue. Basically, the file sets its tempo to 64 in the last order, then repeats to the first order without resetting the tempo, causing subsequent loops to play at the slowed down tempo. XMPlay behaves the exact same way when configured to always loop. The only "fix" would be to reset the tempo and possibly other player state variables on a full loop that isn't triggered by a pattern jump command. Does any known player do that?

[deus-ex]

• methodyne.it - 404. In fact, there doesn't seem to be a Blz directory in the impulsetracker directory at all.

Sorry for the inconvenience, a copy/paste fault. Actually its a Fasttracker 2 module which can be accessed here : methodyne.xm

Also, mudlord reported a looping issue with the module Necroscope by Mantronix/Razor 1911. I'm calling this a non-issue. Basically, the file sets its tempo to 64 in the last order, then repeats to the first order without resetting the tempo, causing subsequent loops to play at the slowed down tempo.

I checked the module available at MODLAND to find that it is a little different to the one downloadable for example at AMP. The MODLAND version does NOT have the issue but instead loops nicely at correct speed. It appears to be the original (non-ripped) module : necroscope.mod

Oh, and thanks for the quick update.

This post has been edited by deus-ex: Jan 11 2011, 20:00

[kode54]

I checked the module available at MODLAND to find that it is a little different to the one downloadable for example at AMP. The MODLAND version does NOT have the issue but instead loops nicely at correct speed. It appears to be the original (non-ripped) module : necroscope.mod

I just downloaded this version, it is identical to the one I already have. With looping set to indefinite, or two or more loops, it loops back to the first order with a tempo of 64.

Also, currently, the frequencies filtered out are at a fixed level relative to the output sample rate, so if you're not getting enough high pitched noise, raise the sample rate.

Oh, and methodyne.xm drum sample pops because it ends on a maximum peak sample. Not even my feeble attempts at volume ramping fix it, because the part in DUMB itself only kicks in for looping samples, and the part in foo_dumb doesn't seem to help much with that sample. And none of that has anything to do with the new resampler. EDIT: Okay, I fixed this one by reducing the requirements for sample end ramping when volume ramping is enabled. Now shorter unlooped samples, down to 65 samples for 16 bit or 33 for 8 bit, will be logarithmically/shift ramped on the end to fix problems like this, but possibly cause problems for intentionally short and poppy samples.

[deus-ex]

With looping set to indefinite, or two or more loops, it loops back to the first order with a tempo of 64.

Well, I checked the looping issue just with XMPlay, there the MODLAND version works fine while the AMP version fails.

Also, currently, the frequencies filtered out are at a fixed level relative to the output sample rate, so if you're not getting enough high pitched noise, raise the sample rate.

Thanks for the hint, I just increased the output sample rate from 44100 to 48000 khz. Let's hope it'll improve things a little.

Okay, I fixed this one by reducing the requirements for sample end ramping when volume ramping is enabled. Now shorter unlooped samples, down to 65 samples for 16 bit or 33 for 8 bit, will be logarithmically/shift ramped on the end to fix problems like this, but possibly cause problems for intentionally short and poppy samples.

Thanks a bunch for yet another tweak. This improves the situation indeed.

[Vagabond]

Kode, do you perchance have much knowledge regarding .AMF files? I am repackaging Crusader: No Remorse/No Regret music for my website, but have run into issues. In short, two of the files do not play properly; wrong instruments, tempo, etc. In addition, they are split into many different files. Through experimentation, I've determined this issue may not be related to a player, but to the files themselves. If that is the case (which is what it most likely is), then I will need to go to the source of the files and everything here will be irrelevant.

There is a thread illustrating my progress on the matter. I've included some recordings of what the music actually sounds like in game ("M07" is crusadermiss7, "M12" is crusadermiss12). When listening to the raw files, it should be clear that they are vastly different.

The files in question—along with some files that are correct—are located here. These are files directly from the game's CD.

I would very much appreciate your help if you can indeed offer any! Thanks for reading.

This post has been edited by Vagabond: Jan 13 2011, 22:36

[kode54]

Along with implementing ProTracker invert loop effect, (EFx) I also implemented two fixes for M07 and M12.

Both files have instruments with base key offsets, a previously unknown field. The byte which follows the default volume level field appears to be a signed base key offset, in semitones. This fixes the slap bass instrument in M07, and several instruments in M12.

M12 also uses the effect number 0x1B, which I've interpreted to be in the XM effect range, and thus effect R, multi-retrigger. Previously, it was being masked with 0x0F to become effect B, the position jump command. This fixes the length being detected as 25 seconds, as well.

[Vagabond]

You are the man. Thank you.

[deus-ex]

This fixes the length being detected as 25 seconds, as well.

During playback of M12 the total song length is reported to be 2:46 min, however the current position marker reaches the end position way before the song has ended and appears to reflect only the first 25 seconds of the module. Stopping playback or advancing to another file in a playlist changes the total song length of M12 to 0:25 min.

Nice fixes for M7 and M12. I never listen to these in the past, probably because of the slightly broken playback, though I wouldn't know that something might be broken. I played the Crusader games many many years ago, so it's quite hard to remember if there's a difference at all.

Thank you, Kode54.

This post has been edited by deus-ex: Jan 15 2011, 12:25

[kode54]

Welp, I've gone and implemented Oktalyzer format support. DUMB is probably also the only PC player now that supports all of the effects correctly. Well, at least, the weird arpeggio effects are suppored correctly. I can't say any of the slides are perfect, considering that portamento and note slides are all implemented on a floating point delta sample speed, so all Amiga style slides and such have to be scaled logarithmically. And I'm not too sure about the whole note slides, I think they're correctly implemented.

Oh, and for anyone developing a player or tracker which supports the Oktalyzer format, the documentation here is incorrect, regarding effects 1 and 2. It has them backwards. It's easy to make that mistake, too, because the reference OKTAplayer.s names the functions rs_portu and rs_portd. rs_portu increases the period, not the pitch. And rs_portd decreases the period, not the pitch.

EDIT: I updated again to make the Oktalyzer loader more tolerant of truncated files. Of course, none of the files on modland are truncated, but apparently, the Amiga ripping tool ExoticRipper can produce files that have the last two bytes chopped off. At least MultiRipper gets it right. Version 2.80 is the last version for MS-DOS, 3.00 beta is a Win32 application.

[deus-ex]

Of course, none of the files on modland are truncated [...]

Heh, I couldn't be this sure like you are since you obviously dived deep into this format, so thank you for stating. I feel a little honored, I mean it's like it has a "Quality-approved by Kode54" tag on it.

Is there anything you can do about the song length issue of the Asylum module M12 I reported in my previous post?

[kode54]

Yes, reload file info for the module so the reported length will be updated to the correct value. foobar2000 caches it, along with all other file info, when the file is first loaded, and doesn't update the stored information until the file modification timestamp changes, or until a manual reload is forced. The fact that the correct time displays when playing the file is some sort of fluke, I guess.

I just uploaded another fix, this time for the static sample end ramping I apply when volume ramping is enabled. It was kicking in for samples with sustain loops, but no normal loops, which was affecting Oktalyzer modules because they use sustain loops instead of normal loops. Now it will subtract the sustain loop end when calculating the length available for ramping, and when it actually does ramp, it will only ramp outside of the sustain loop.

[deus-ex]

Yes, reload file info for the module so the reported length will be updated to the correct value.

Ah, so I managed to fool myself. I do not use predefined playlists for the Asylum modules so I thought I wouldn't be affected by the caching effect. However for comparison reasons I first played the Asylum modules M7 & M12 using foo_dumb v0.9.9.27, then
closed foobar and overwrote the plugin with the new v0.9.9.28, then started up foobar again. Because foobar uses temporary playlists which aren't refreshed when playing back the same set of files again the caching effect kicked in.

Thanks for the hint, all is well now of course.

P.S.: With your recent fixes to foo_dumb I now like to listen to the Asylum modules M7 and M12, too, which I completely ignored previously. So thanks again for your dedication into all of this, very much appreciated. *thumb-up*

[FF / MFG]

Hi. Can you check heavy clipping with 0.9.9.31 in "Party On Funk-o-Tron"?
Composer: Dynamic Harmony
C A R C A S S P C 1 9 9 6
CCS-TRON.ZIP
DH-POFOT.XM

With any interpolation on, bass line clips terribly (see around 1:40-1:50 for example). I think there's some clipping without interpolation anyway, but it's much less noticeable.

I've tried to check against xmplay, and it plays fine there. First I didn't notice autoamp feature. But after disabling it xmplay still has much, much quieter output. With autoamp enabled it goes to -1.1db with sinc interpolation.
Is there any automatic amplification employed in foo_dumb? I've tried to use foobar's preamp to lower volume and it requires significant adjustment to fix the clipping. In fact, I just did replaygain scan and it gave -6.17db, 1.86 peak without interpolation. Oh, oh. And -6.29db, 2.25 (!) peak with cubic interpolation. There, that's some hard numbers and not just my eyes and ears deceiving me.

[kode54]

Either turn on tagging and apply the ReplayGain (or R128Gain, if you prefer) scan results to the file, or use a peak limiter such as the Advanced Limiter. Or, for more consistent loudness without tagging, use a normalizer/compressor DSP such as my R128Norm component.

Note that the audible clipping will not be such a problem without any DSPs if you are using Windows Vista or newer with the default DirectSound output, as the operating system's sound mixing subsystem automatically performs compression where peaks exceed +/- 1.0.

[FF / MFG]

Either turn on tagging and apply the ReplayGain (or R128Gain, if you prefer) scan results to the file, or use a peak limiter such as the Advanced Limiter. Or, for more consistent loudness without tagging, use a normalizer/compressor DSP such as my R128Norm component.

Note that the audible clipping will not be such a problem without any DSPs if you are using Windows Vista or newer with the default DirectSound output, as the operating system's sound mixing subsystem automatically performs compression where peaks exceed +/- 1.0.

I would really prefer to not modify the modules. Compressor DSP's have to be turned off for normal music.
And I'm still on XP.

Why the module is so loud with foo_dumb in the first place? And why interpolating gives ~+0.5 peak value? I realize peaks could be higher after any processing, but that much is suspicious to me.
I realize ReplayGain would be a good solution for this (disregarding my reluctance to modify the modules), but this peak difference would mess up even ReplayGain, because sometimes I listen with interpolation, and sometimes I prefer no interpolation.

[Canar]

The module is loud because foo_dumb isn't working behind the scenes to stop it from being so. Layer eight sounds recorded at -6dB and you can get theoretical peaks of 12dB over if everything goes wrong in exactly the right way.

[kode54]

I may add an option in a future version of foo_dumb to apply ReplayGain scale to a given module, if it happens to be a supported format that has a global and/or mix volume field in its headers. That way, the volume should be normal no matter which (properly configured) player you open it in. It may be useful for composers as well, in case they can't trust their tracker to not perform automatic gain reduction on files which are too loud.

[kode54]

Fixed invert loops again. The subsong/length scanner was modifying the module that was already loaded by the caller as if a full loop of each subsong was already played. Now it performs a second module load so that no sample modifications are applied to the caller's instance of the data before playback. This fixes the intial playback of any module which uses invert loop effects.

I also fixed the subsong/length cache so it does first-in-first-out reordering properly. Previously, when it found a cache hit, it would merely swap it with the last item in the list instead of removing it and re-adding it to the end.

[Rotareneg]

I've noticed that foo_dumb is reducing stereo separation (mixing the left and right channels a bit) with all the Amiga game music mods I've got. Is there any way to stop this, maybe with an adjustable setting?

This post has been edited by Rotareneg: Mar 5 2011, 19:12

[kode54]

There is no way to configure that currently, as it is hard coded. In fact, it's hard coded separately for each format which is normally hard panned. I'll look into adding an option to change the panning percentage for hard panned files. (As I'm pretty sure that most files which support soft panning are panned in a manner which would be comfortable for most listeners. Or maybe I'm unusual in thinking that sound should be composed for the possibility of headphone listeners who don't have the benefit of a system-wide speaker virtualization or crossfeed filter.)

[Rotareneg]

What, you don't like the feeling that the music is trying to split your head apart when using headphones?

I mostly use speakers, and had been playing the games via an emulator. When I played the music in fb2k I noticed that the music didn't sound as "wide."

[kode54]

Uploaded 0.9.9.38, which fixes IT New Note Actions for duplicate check types of sample and instrument, which previously failed outright. Spot the error:

CODE

                if (playing && playing->channel == channel && playing->instrument->dup_check_type) {
                    int match = 0;
                    switch (playing->instrument->dup_check_type)
                    {
                    case DCT_NOTE:
                        match = (channel->truenote == playing->note);
                    case DCT_SAMPLE:
                        match = match && (channel->sample == playing->sampnum);
                    case DCT_INSTRUMENT:
                        match = match && (channel->instrument == playing->instnum);
                        break;
                    }

Thanks to Kieran Menor for calling this to my attention.

Configurable stereo separation for hard panned formats coming soon, maybe. I just need to add extra functionality to my frontend loaded code, since there's no state available early enough for the loaders themselves to be modified to check some configuration variable.

[BoingBoomTschak]

foo_dumb module decoder settings for mp3 conversion:

I would like to encode XM files to MP3 files with foo_dumb. I have installed foo_dumb in foobar2000 and on the dumb module decoder settings window I have put the following options:



I have got lame3.98.4 installed in foobar2000 as well and there chosen the best quality for conversion/encoding. What else do I need to know about how to convert XM files?

Thanks for any help.