The short gap at the start of an MP3 exported from Audacity is encoder delay, and Audacity's manual describes it as a limitation of the MP3 format rather than a fault in your project.
That changes what you should try. Trimming the timeline does not remove it, and the very same file can look clean in one application and padded in another — which is exactly why this problem is so hard to pin down.
What the silence actually is
The MP3 Export Options page in the Audacity Manual states it directly:
"Note that MP3 files have a short silence at the beginning due to encoder delay. This is a limitation of the MP3 format. Audacity uses LAME Mp3 info tag to store the exact length of added silence. Applications that support this tag, (including Audacity), are then able to automatically strip off the added silence. Many apps still do not support this feature, and will therefore show a small amount of added silence at the beginning of the file."
Three separate things are packed into that paragraph, and each one explains a symptom people usually report as a different bug:
- The silence is added during encoding. It is not something you recorded, and not something the editor put there. Audacity uses LAME for MP3 encoding, and the manual attributes the gap to the encoder's delay.
- The exact length is written into the file. That is what the LAME Mp3 info tag is for — the file itself carries the information needed to undo the padding.
- Whether it gets undone depends on what opens the file. Audacity is named as an application that supports the tag and strips the silence automatically. Applications that do not support it show the padding.
That third point is the whole diagnostic trap. If you export an MP3 and immediately re-import it into Audacity to check your work, Audacity removes the added silence and the waveform looks fine. Hand the identical file to a player or a DAW that ignores the tag and the gap is back.
One number you will not get from that page: it calls the gap "a short silence" and points at the tag for the exact length instead of publishing a figure. If you have seen a specific millisecond value quoted somewhere, it did not come from this page — check the official documentation before you build a workflow around a fixed duration.
The real fix: don't ship MP3 where the start matters
The manual makes the recommendation itself, in the same paragraph:
"If you need to synchronize files or are making Audio Loops, it is highly recommended to use a format that does not have this limitation, such as WAV, FLAC or Ogg Vorbis."
Three options, and they are not interchangeable. Audacity's own format comparison table gives File size (MB per minute) at default Audacity settings — 44,100 Hz sample rate, and default bit rate or quality settings for the compressed formats. Where VBR compression is used, the manual notes the achieved size varies with the content.
| Format | Lossy | Mono | Stereo |
|---|---|---|---|
| WAV 16-bit PCM | No | 5.0 | 10.0 |
| FLAC 16-bit | No | 2.5 | 5.0 |
| Ogg Vorbis | Yes | 0.5 | 1.0 |
| MP3 | Yes | 1.0 (CBR) | 1.0 (CBR) |
Pick WAV if the file is going into another editor, a sampler, or anything that needs to line up frame-accurately. Pick FLAC if you want the same lossless audio at roughly half the size — the manual describes FLAC files as "about half as large as the uncompressed WAV or AIFF formats". Pick Ogg Vorbis only if the small size is the priority and the destination can play it; the manual notes that Ogg "can be played in Windows Media Player and Apple Music/iTunes, but requires additional codecs to be downloaded", which makes it a poor choice for a file you are sending to someone else.
Keep the master lossless, convert only at the very end
The same page is blunt about the wider habit:
"So never do production work in MP3, instead work with a lossless format such as WAV, AIFF or FLAC and for final use then export to MP3."
Which gives you a workflow that sidesteps the problem entirely: export once from Audacity as WAV, keep that as your reference for anything involving sync or loops, and produce the MP3 as a separate delivery step from that finished WAV.
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
Be clear about what this does and does not solve. Any MP3 is still an MP3 — the manual says the leading silence is a limitation of the format. What the split buys you is that your master never passes through an MP3 encoder, so the timing you hear in Audacity is the timing your WAV keeps, and the MP3 becomes a distribution copy rather than the file you cut against. The WAV to MP3 converter runs in the browser tab; see all Clapr tools for the reverse direction.
Other causes, in order of likelihood
1. A real leading gap in the project
This one is not encoder delay at all, and it is far more common than people expect because it is on by default. The Export Audio dialog has a Trim blank space before first clip option, and the manual describes both states:
"If this is unchecked (default setting) when exporting audio any leading blank space offset in the tracks or project to be exported is treated as silence and appropriate leading silence will pad the exported audio."
"If you check this box, leading blank space will be ignored on Export."
So if your first clip does not start at zero, the default behaviour bakes that offset into the export as real silence. Encoder delay is described only as "a short silence"; a timeline offset is as long as the offset. If the gap is clearly audible rather than a click's worth of padding, check this box first — or drag the clip back to the start.
2. The app opening it ignores the LAME Mp3 info tag
Worth listing separately, because it is what makes the problem look intermittent: the same export behaves differently in two applications, and Audacity is one of the ones that hides the padding.
3. Trying to fix it with export settings
The MP3 Export Options page documents sample rate, four bit rate modes, and the quality presets. None of those controls concerns the leading silence, and the page attributes the silence to the format rather than to a setting. Re-exporting at a higher bit rate changes the file size, not the start of the file — and if the source was already an MP3, the manual warns you lose quality twice.
How to tell it worked
Test in the application that will actually play the file, not in Audacity. Because Audacity supports the tag and strips the added silence, re-importing your MP3 tells you nothing about how it behaves elsewhere.
If you switched to WAV or FLAC, the check is simpler: import the exported file back into Audacity and confirm the waveform starts at zero. Any gap there came from the timeline, not an encoder — which sends you back to the trim option above.
FAQ
How long is the silence Audacity adds to an MP3? The MP3 Export Options page calls it "a short silence" and says the exact length is stored in the LAME Mp3 info tag rather than giving a figure. Specific millisecond values circulating online do not come from that page — check the official documentation if you need a number you can rely on.
Why does the gap disappear when I re-import the MP3 into Audacity? Because Audacity supports the tag. The manual names it explicitly: applications that support the LAME Mp3 info tag "are then able to automatically strip off the added silence". Many other applications do not, and those are the ones that show the gap.
Does exporting at a higher bit rate get rid of it? No. The manual ties the silence to encoder delay and calls it a limitation of the MP3 format. Worth knowing while you are in that dialog: Audacity's default MP3 setting is not 128 kbps — the page states "The default MP3 encoding options in Audacity are 170 - 210 kbps VBR (preset "Standard")". 128 kbps is the default for the Constant bit rate mode.
What should I export for loops or anything that has to sync? WAV, FLAC or Ogg Vorbis — that is the manual's own recommendation for synchronizing files and making audio loops. WAV for maximum compatibility, FLAC when size matters and the destination reads it. More MP3 export troubleshooting lives in the fix guides, and DaVinci Resolve MP3 export covers the same question from the video side.
Do I still need to install LAME to export MP3 from Audacity? Not on Windows or Mac. The manual states that the software patent on the LAME encoding library has expired and "now the LAME library for MP3 export is built-in with Audacity for Windows and Mac". Linux users, in its words, "will still need to download and install the free and recommended LAME third-party encoder to export MP3 files from Audacity".
Quotations from the Audacity Manual pages MP3 Export Options, Export Audio Dialog, Export Formats supported by Audacity and FAQ: Installing the LAME MP3 encoder, checked 16 September 2026.
