1

(using jfugue 5.0.9) I wanted to convert .mid to .txt (staccato), and later to .mid again, to confirm conversions worked. Both .mid (original and converted) should be equal ideally, but the converted (midi -> staccato -> midi) file has weird delayed notes, and one enlargened note duration. JFugue probably struggles because the midi is a human, hyper-sensible recording. Is there any way to fix this?

Heres the 3 files https://drive.google.com/drive/folders/1DepX0lCqNaIRCoHRfGwBRsO1xRFCbCpl?usp=sharing

And here are the 2 methods used:

public static Pattern convMidToStac(String fileName, boolean makeAFile) {
    
    Pattern p = new Pattern();
    
    // Convert midi file to a JFugue Staccato pattern.
    try {
        p = MidiFileManager.loadPatternFromMidi(new File("D:/eclipse-workspace/MidiReader/" + fileName + ".mid"));
        
        if (makeAFile) {
            makeFile(fileName, p.toString());
        }
        return p;
        
    } catch (Exception e) {
        System.out.println("An error occurred.");
        e.printStackTrace();
        
        return null;
    }
}

public static void convStacToMid(String fileName) {
    
    Pattern p = new Pattern();
    
    try {
        p = MidiFileManager.loadPatternFromMidi(new File("D:/eclipse-workspace/MidiReader/" + fileName + ".mid"));
        
        File filePath = new File("D:/eclipse-workspace/MidiReader/" + fileName + "MIDI.mid");            
        
        MidiFileManager.savePatternToMidi(p, filePath);
        
    } catch (Exception e) {
        e.printStackTrace();
    }
}
SuperStormer
  • 4,997
  • 5
  • 25
  • 35
some dude
  • 11
  • 1
  • What you're seeing in the MIDI-to-TXT is JFugue's attempt at taking a MIDI file, which does not have explicit timing information for notes (and representation at all for rests), and calculating what the durations ought to be. If the MIDI file was played by a human instead of quantized by a computer, you'll see a lot of variability in the resulting numbers. I'll look at the files more closely to make sure the math is right. Because of this conversion and other aspects of MIDI data, we can never expect input.mid to equal output.mid byte-for-byte, but if this works, they should sound the same. – David Koelle Mar 03 '22 at 06:34
  • Right! I hope theres a solution to those out-of-place notes, to have them the closest possible to the original midi! but of course both files wont be exactly the same! ty – some dude Mar 03 '22 at 23:45
  • If anyone knows a fix or any kind of alternative it'd be good to know since i need this for a project xd – some dude Mar 08 '22 at 18:48
  • For what it's worth, it looks like the error is in reading the MIDI file and translating it to a JFugue Pattern, not with converting the Pattern to an output MIDI file. Not sure if that helps you, but that's where I've gotten so far. – David Koelle Mar 09 '22 at 02:09
  • Ok, I appreciate the update – some dude Mar 09 '22 at 03:46
  • I've loaded both MIDI files into a music editor (Noteworthy Composer). The melody is mostly the same, but it looks like a few notes are misplaced in time in the staccatoToMidi file. I realize "mostly the same" doesn't mean much when there's still a bug somewhere, so the question is why a few notes seem to be misplaced. Anyway, this seems to rule out duration calculations as a source of error (i.e., notes like 'A5/0.06614583333333333a26d0' seem generally correct) – David Koelle Mar 09 '22 at 05:15
  • Interesting. I've seen 1 note duration was much larger than it should be too, but it looks like that mistake is appreciably rarer than -note placement in time- type of errors – some dude Mar 10 '22 at 02:26

0 Answers0