Print

[jcxz100]

Hey

I have used MilkyTracker for many years - and FastTracker II before that (starting 1997!)
I have always exported as 44.1 kHz but recently I tried 48 kHz.
Unfortunately I have found out that these exports are longer (and slower) than if I export at 44.1 kHz.
This is a problem as I have vocals and sound effects (not in XM) at 44.1 kHz that I mix in. Suddenly they are out of sync.

I first noticed this when I did a screen capture video of MilkyTracker running and tried to overlay a 48 kHz audio minimix - the lengths didn't fit, and I had to shrink the minimix by 0.230 % (in Audacity).

These are my findings (lengths as M:SS:HHH):
- screen capture of playback (at both 48000 and 44100 Hz): 5:13:700 (approximately).
- export at 44100 Hz: 5:13:725.
- export at 48000 Hz: 5:14:432.

---

I have verified this on two laptops:

Windows:
- Software: MilkyTracker v0.90.86 (the latest official).
- OS: Windows 10 64bit.
- Machine: Acer Pavilion DV6, AMD processor (details unknown).
- Audio Card: AMD High Definition Audio Device (details unknown).

Linux:
- Software: MilkyTracker git commit a3ae038ac7d46a1d06834e794f00f0d3480ec24c.
- OS: Linux Mint 17.2 Cinnamon 64bit.
- Machine: An ancient Thinkpad t61, Core2 duo.
- Audio Card: Intel Corporation 82801H (ICH8 Family) HD Audio).

(As far as I can tell the issue hasn't been addressed since this git commit - I haven't tried building a newer).

// Lasse

[Saga Musix]

This is to be expected as part of the legacy "tempo" concept of trackers.
The tempo factor (Fxx command) determines the length of a single tick, and this length is computed with integer precision. The term to compute this length depends on the tempo itself but also the sampling rate.
Since the fractional parts of the term are discarded, the rounding error is different for 44 KHz and 48 KHz, leading to slightly different tick durations. This difference will add up very quickly, since a song typically consists of thousands of ticks.
Hence: This is not a bug but expected legacy tracker behaviour.

If you need to expert a specific song and are able to edit it a bit, you can try using OpenMPT, convert the XM module to the MPTM format (beware, this can change the behaviour of several pattern formats, so it will most likely sound a bit different) and then use the MPTM format's "modern tempo mode" (beware again, this can change the tempo compared to classic tracker tempo, there are some explanations here). Modern tempo mode has no rounding errors and thus always uses the correct tempo.

[jcxz100]

Thanks Saga Musix; that makes sense.
Sort of.

But why then is the playback at 48000 the "correct" (expected by me) length??

// Lasse

[Saga Musix]

Taht depends on why you "expected" it. It's of course entirely possible that the rounding error is smaller at 48 KHz, but depending on the tempo it could also be bigger. It's hard to tell if you don't show the actual module.

[jcxz100]

Saga Musix - I'm not sure I was clear there.
What I don't get is this: When I screen capture the playback of my song, it is the same length as the exported 44.1 kHz WAVs (within uncertainty of 100 ms or less).
And that goes for both 44.1 and 48 kHz playback.

The difference between the exported 44.1 and 48 kHz WAVs on the other hand is roughly 700 ms.



Is *this* a bug??

[Saga Musix]

Well the problem here is that there are several factors that can play into it. For example it might depend on the audio driver you selected in Milky - some audio drivers may force a certain sample rate to be used and Milky might not communicate this to you. I'm not a Milky developer so I don't know exactly how Milky would deal with such situations.
I tried it with the DirectSound driver in Milky and my test tune exported at 44 KHz was exactly as long as when played back live at 44 KHz, and my test tune exported at 48 KHz was exactly as long as when played back live at 48 KHz - just as you'd expect it.

All I can say that the behaviour you get during WAV export is expected and correct, but how it correlates with real-time playback can depend on a lot of things. Of course human error is also possible, i.e. maybe you just accidentally swapped two video files and assumed that they'd have the same length?

[jcxz100]

OK - got it now.
My linux sound card was set at 44100 Hz; I can see how that would force Milky to adopt same freq. Unfortunately didn't test the screen capture on Windows, in which case I would probably have figured this out myself.

Thanks a lot :-D


(Btw: About swapping files - been there, done that! But not this time :-P )

[Saga Musix]

Glad you could solve it, or at least understand why it happens.
I'll move this out of the bug report forum then, other people might find this information interesting as well.