The short answer: MIDI to OGG makes the file smaller — it turns the rendered audio into a .ogg. It is not one conversion but two decisions stacked in the right order. Step one renders the notes through a soundfont — a MIDI file holds no audio at all, only note numbers, velocities and tick positions, so something has to turn those into samples, and whatever does that is what you actually hear. Step two encodes those samples into the .ogg container at a bitrate you choose. Step one decides the sound. Step two decides the size. That separation is the whole subject of this page. (This page is the recipe, not a converter — the tool on this site runs the other direction, audio in and MIDI out.)
| Step | What goes in | What comes out | What it decides | What it cannot fix |
|---|---|---|---|---|
| 1. Render | the .mid plus a .sf2 soundfont | audio samples (WAV, or straight into the encoder) | the instrument, the tone, the attack and decay, what velocity sounds like | notes that were never in the MIDI file |
| 2. Encode | those audio samples | a .ogg file | file size, and how much of the audio survives the codec | which instrument you hear, or a silent render |
Pages that rank for this phrase skip the first step: they do not say that a synthesizer has to turn the notes into sound, and they do not separate that step from the encoder setting that decides the file size. The command that most people end up copying does both steps in one line, and it is worth reading it as two halves rather than one:
fluidsynth -nli -r 48000 -o synth.cpu-cores=2 -T oga -F example.ogg /usr/share/soundfonts/FluidR3_GM.sf2 example.MIDRead left to right, -T oga is the encoder half and FluidR3_GM.sf2 is the soundfont half. The one thing this line cannot do is set a bitrate — -T oga writes OGG at whatever the library defaults to. So if you want to choose between 96 and 192 kbps, split the line in two and let the second half do the encoding:
# step 1: notes -> audio, no encoder involved yet
fluidsynth -nli -r 48000 -o synth.cpu-cores=2 -T wav -F example.wav /usr/share/soundfonts/FluidR3_GM.sf2 example.MID
# step 2: audio -> .ogg at the bitrate you pick
oggenc -b 96 example.wav -o example-96.ogg
oggenc -b 192 example.wav -o example-192.ogg| Setting | What it is good for | What to expect on size |
|---|---|---|
-b 96 | a preview, a game asset, anything played through small speakers where the top octave is not the point | asks for roughly half the bits per second of 192, so expect a file in that neighbourhood rather than an exact half — Vorbis is variable-bitrate |
-b 192 | a file you will actually listen to, or feed back into an analyser later | the safer default of the two if the .ogg is the deliverable and not a stop on the way somewhere |
One honest note before the rest: we did not run either of those two commands on this machine. There is no fluidsynth and no oggenc here, so the bitrates above are settings we are telling you to choose between, not results we measured. What we did measure is the encoding step itself, on codecs we could run — further down, with the numbers.
1. What is actually inside the .mid you are starting from
This matters because it explains why step one cannot be skipped. The MIDI writer on this site produces a format 1 file with two tracks and 480 ticks per quarter note. Track one holds the tempo and the time signature and then stops. Track two is nothing but note pairs: a note-on with a pitch and a velocity, later a note-off with the same pitch. There is no sample in the file, no waveform, no envelope, and no audio of any kind.
The timing is in ticks, not milliseconds. At 480 ticks per quarter note and 120 BPM, one tick is 1.042 ms and a sixteenth note is 120 ticks, or 125 ms. A renderer turns those tick positions into sample positions using the tempo in track one — which is why the same .mid rendered at a different tempo is a different length of audio.
Velocity is an integer from 1 to 127, one value per note; on this writer the top value 127 arrives at −2.22 dBFS of the original audio. That integer is the only thing standing in for loudness, and what it sounds like is not in the file either — it is whatever the soundfont maps it to. If you want the byte-level layout of the file you are about to render, what is actually inside a MIDI file walks the same two tracks message by message.
2. Step one: the soundfont is the instrument, and it is not in the file
A .sf2 file is a set of recorded samples plus a map that says which sample plays at which pitch and velocity. That is the entire reason two renders of one .mid sound like two different recordings: the notes are identical, the sample set underneath them is not. Nothing in the .mid prefers one soundfont over another, because nothing in the .mid describes a sound.
Two consequences are worth knowing before you pick one. First, this writer emits no program change — the note track is note-on and note-off only, with no instrument assignment anywhere in the file. A renderer therefore plays it with the soundfont's default patch rather than an instrument the file asked for. If you expect strings and get a piano, that is not a bug in the MIDI; the file never asked for strings. Second, velocity is quantised by the library. The writer can put 127 distinct values into a note, but a General MIDI soundfont maps velocity onto a small number of recorded layers, so neighbouring velocities can collapse onto the same sample. We did not measure how many layers a given .sf2 carries — that number belongs to the library, not to us — but the direction is fixed: the finer the dynamics in your .mid, the more of them a small soundfont will flatten.
3. Step two: the encoder decides the size, not the notes
Once step one has produced samples, the notes are already fixed. An encoder can blur them, but it cannot invent one or delete one, and the measurements we have say the blur is small. On this site's own analyser, a known eight-note source re-encoded as MP3 at 320, 192, 128 and 64 kbps came back with all eight notes at every bitrate, velocity moving by at most one step (mean 0.75). The same source through AAC at 64, 128, 192 and 256 kbps decoded back to within 0.02 dB of the original level.
Those are MP3 and AAC numbers, not Vorbis numbers. OGG normally carries Vorbis or Opus, and there is no encoder for either on this machine, so we are not going to put a Vorbis figure on the page to make the table look complete. Both are lossy codecs in the same family as the two we did measure, and the shape of the result — notes survive, size changes — is the shape you should expect. If you want to check it on your own file rather than take that on faith, the round-trip test at the end of this page does exactly that.
The practical reading: if your .ogg comes back with the wrong instrument, wrong octave or no sound at all, the bitrate is not your problem and moving from 96 to 192 will not fix it. Go back to step one and change the soundfont.
4. Why the usual result is a file with no sound
The thread that tends to rank for this phrase is somebody holding a .ogg that will not play, and an Audacity that will not export OGG. Both symptoms come from the same place, and it is not the codec. There are two ways to end up there.
The first is a renamed file. A .mid renamed to .ogg is still a .mid — the extension is a label, not a conversion, and no samples were ever created. Players that sniff the content will open it as MIDI or refuse it; players that trust the extension will hand it to a Vorbis decoder, which will fail or produce silence. The tell is size: a MIDI file of a few minutes is measured in kilobytes, while a real OGG of the same music is measured in megabytes.
The second is a skipped step one. Something encoded the file, but what it encoded was not audio. This is what happens when a tool offers a MIDI-to-OGG button and quietly shells out to a renderer that is not installed, or renders with an empty soundfont. The file is a valid OGG container with valid Vorbis frames inside, and the frames contain near-silence. No amount of re-encoding fixes that, because the information was never rendered in the first place.
5. MIDI to MP4 and MIDI to FLAC are the same two steps
Once you see the split, the other containers stop being separate problems. They differ in what step two costs you, and in nothing else.
| Target | Is step two lossy? | What that means for you |
|---|---|---|
| MIDI to FLAC | no — lossless | the cleanest experiment available: step two is free, so everything you hear came from the soundfont. If two FLAC renders of one .mid sound different, the soundfont is the only possible cause. |
| MIDI to MP4 | yes, normally AAC inside the video container | step two is lossy in the same way AAC is, and you additionally decide whether the file carries a video track at all. A still image plus the audio is a valid MP4; the picture has no effect on the notes. |
| MIDI to OGG | yes, Vorbis or Opus | the default for game assets and web audio: small files, and a bitrate you choose at encode time. |
| MIDI to AIFF | no — lossless | behaves like FLAC for this purpose, with a larger file and wider support on older Apple software. |
The reverse direction is a different story, and it is the one this site actually does: OGG to MIDI has to decode the container first, and the numbers there are about what survives that decode. Going the other way — MIDI to MP4 — the audio path is the same as above; if you already have an MP4 and want the notes out of it, MP4 to MIDI is that page.
6. What this page does not do
This site's converter reads audio and writes MIDI. It has no synthesizer, no soundfont and no OGG encoder, so it cannot turn a .mid into a .ogg for you, and nothing on this page should be read as a button that will. The two-step recipe above is the honest path, run in your own terminal with your own soundfont.
What the converter is good for here is the check at the other end: once you have an .ogg, you can drop it back in and see whether the notes you rendered are still there. The same boundary applies to the other container pages — MIDI to MP3 and MIDI to WAV explain why this tool stays out of the render-to-audio direction entirely.
7. How to check your own file
Four checks, in the order that finds the problem fastest.
- Look at the size. A few minutes of MIDI is kilobytes. A few minutes of real OGG is megabytes. If your
.oggis the same size as the.midit came from, nothing was rendered and nothing was encoded. - Ask the file what codec it holds.
ogginfo example.oggorffprobe example.oggwill name the codec (Vorbis or Opus) and the nominal bitrate. A file that reports no audio stream is not an audio file, whatever the extension says. - Play it somewhere with no MIDI synthesizer. A browser tab or a phone has no General MIDI bank. If the file is silent there but "plays" in a MIDI player, you are listening to the player's synth, not to your file.
- Round-trip it. Drop the
.ogginto the converter and read the piano roll. The analyser decodes to 22,050 Hz mono and works in 11.610 ms frames across a 55–1,800 Hz search window, so a file that really contains your render will hand the notes back. A file that was never rendered hands back nothing.
Questions people actually ask
Can this tool convert a MIDI file to OGG?
No. This converter goes the other way: audio in, MIDI out. There is no synthesizer and no encoder in it, so a .mid dropped here is not a supported input at all. For the direction this site does handle, OGG to MIDI is the matching page; for the recipe in the other direction, the two commands at the top of this page are the whole answer.
Which soundfont should I use?
We do not recommend one, because the choice is the point rather than a detail — picking a soundfont is picking the instrument. Three questions sort it out faster than any ranking: does it follow the General MIDI map (so program numbers mean the standard instruments), how large is it (a big library carries more velocity layers, so your dynamics survive), and does it have the instrument you actually want rather than a piano standing in for everything. A General MIDI set is the sane default for a first render.
Does a higher bitrate make the notes more accurate?
No. By the time the encoder runs, the notes are already in the samples and the encoder is only deciding how faithfully to store them. On this site's own analyser, MP3 from 64 to 320 kbps kept all eight notes with velocity moving by at most one step, and AAC from 64 to 256 kbps landed within 0.02 dB of the source level. Bitrate buys audio fidelity, and even then it barely touches what an analyser recovers.
Why is my .ogg silent?
Because it was never rendered, or never encoded. A .mid renamed to .ogg contains no samples at all, and a file produced by a tool whose renderer was missing contains valid Vorbis frames holding near-silence. Check the size first — kilobytes instead of megabytes is the giveaway — then run ogginfo to see whether there is an audio stream in there.
Is OGG better than MP3 for this?
For note recovery, we cannot claim it is, because we have not measured Vorbis on this machine and will not guess. Both are lossy codecs, and the two lossy codecs we did measure (MP3 and AAC) both preserved every note in the test. Choose OGG for the reasons it is normally chosen — small files, open format, fine-grained bitrate control — and choose the soundfont for the sound.
If you already have the .ogg and want the notes back out of it, drop it into the Audio to MIDI Converter — it decodes the container first, then measures, so the round-trip check above takes one file and a few seconds.
Related guides
- OGG to MIDIWhat the container actually changes (and what it doesn't)
- MIDI to MP3What this tool covers, and what a synth does instead
- MIDI to WAVWhy the Play button is a synth but not an export
- MIDI converterWhat is actually inside a MIDI file
- Clean up a converted MIDIThe 5 passes that turn a raw export into a usable part
- MIDI to sheet musicWhat this tool covers, and where the score comes from
- Sheet music to MIDIWhy this tool listens to audio, not reads scores
- Audio to sheet musicWhere a chord's notes actually land, measured
- MP3 to sheet musicWhether the codec moves anything the page would show