offset/starting time issue of a MIDI file

[tracyhenry]

Hi, this is an awesome library and I've been using it for a while.

My main use case is to parse a MIDI file to get the absolute times of all "note on" events. Recently, I came across this interesting MIDI file which would make the library output seemingly wrong start times. Every note is off by ~0.4 seconds. Here're some details.

First, the MIDI looks very weird in Logic already. It would start at negative times (normal files start at 01:00:00):

According to Logic, the first note starts at 01:00:04.925 - 00:59:57.6 ~= 7.3s which matches the audio file generated by Logic.

7.3s is also the output of MIDO (a python MIDI library).

In dryWetMIDI, I used the following code to calculate the starting time of the first note. It outputs a different number (6.935s).

    double getAbsoluteTimeInSecondsOfSpan(long t)
    {
        return TimeConverter.ConvertTo<MetricTimeSpan>(t, tempoMap).TotalSeconds;
    }

    midiFilePath = "xxxxx";
    midiFile = MidiFile.Read(midiFilePath);
    tempoMap = midiFile.GetTempoMap();
    notes = midiFile.GetNotes().ToList();
    Debug.Log(getAbsoluteTimeInSecondsOfSpan(notes[0].Time));

Appreciate any idea on why this is the case... I must have recorded the MIDI in a weird way in Logic. But I'd like to be able to handle such weird MIDIs.

I'm on Mac M1 Pro. I couldn't find the dryWetMidi version somehow... lmk where to look for it if you need it. Thank you very much.

[melanchall]

Hi,

Hmm,. interesting. Can you show me the getAbsoluteTimeInSecondsOfSpan method? In your code I don't see usage of DryWetMIDI API to get the time.

Update

Thanks, I see the code now.

Short answer

DryWetMIDI works correctly.

Long answer

Well, I've parsed the file with DryWetMIDI and here what we have:

• Time of the note in ticks is 5868.
• The file has tempo (T) change at 1920 ticks, tempo changes to 600,000 μs (microseconds) per quarter note.
• Time division of the file is 480 ticks per quarter note (TPQN).

Also according to MIDI spec the default tempo is 500,000 μs per quarter note. If we know TPQN and T, we can always calculate the length of a tick in microseconds:

$$\frac{T}{TPQN}$$

So since the time of the note is 5868 and we have tempo change at 1920, we can split 5868 into two time segments:

1. with length of 1920 ticks and tempo of 500,000 μs per quarter note;
2. with length of 3948 ticks and tempo of 600,000 μs per quarter note.

Applying the formula above we can convert 5868 ticks to microseconds:

$$\frac{1920 * 500000 + 3948 * 600000}{480}=6935000$$

So the answer is 6,935,000 microseconds or 6 seconds 935 milliseconds. I don't see any issues with how the library calculates metric time.

[tracyhenry]

thank you, I will open an issue in the mido repo and report back.

[melanchall]

@tracyhenry Thank you! Can you please put the link to an issue here so I can track it too? You have a really interesting case :)

[tracyhenry]

of course, will do. You are awesome!

[tracyhenry]

I found out that mido actually was able to output the same value as drywetmidi. I was using it wrongly. Now Logic Pro is definitely wrong haha.

[melanchall]

Great, thanks!