Why Split MP3 Parts Start With Silence

Every MP3 file carries a few hundred samples of encoder padding at its start, and our splitter writes each part as a brand new MP3, so every part gets its own. In our measurement that padding is 1105 samples, about 25 milliseconds at 44.1 kHz, at the start of each part, plus another 479 samples at the end. Most software is told to skip it, so you usually never hear it, and a file decoded by ffmpeg comes out at exactly the right length. A player or editor that ignores the gapless information will play the silence. That is where the tiny gap, the late start or the part that is a few milliseconds too long comes from. Your cut points are not wrong, and no audio from the song was lost. The padding is a property of the MP3 format, and the [Audio Splitter](/audio-splitter) simply creates a fresh MP3 for every part.

We generated a 60 second stereo 44.1 kHz test tone, encoded it as MP3 with the same libmp3lame quality setting our splitter uses (`-q:a 2`), and cut it into three 20 second parts with the same argument order the engine uses: `-i` first, then `-ss` and `-t`. Each part reported a start time of 0.025057 seconds and a duration of 20.035918 seconds, not 20.000000. Three parts therefore add up to 60.108 seconds against the original's 60.029. Decoding each part normally gave exactly 882000 samples, and the three together gave exactly the 2646000 samples of the source, so nothing audible is missing or duplicated. Switching the decoder's trimming off (`-flags2 +skip_manual`) gave 883584 samples per part, which is 1584 extra: 1105 at the start and 479 at the end. Caveat: this is native ffmpeg 6.1.1 on the command line with the engine's arguments, not ffmpeg.wasm in a browser, and we did not test any particular music player.

To see whether the padding is audible silence, we ran a second check. , we cut a 20 second part out of a loud white-noise file and decoded it with trimming switched off. The first sample above roughly 9 percent of full scale (3000 out of 32767) sat at position 983, which is 22.3 milliseconds in. With normal decoding the same file started loud at sample zero. So the size is the one we measured above, about 25 milliseconds before the music begins, plus about 11 milliseconds of tail. That is short enough to pass unnoticed in a spoken recording and long enough to hear as a hiccup if you play two parts back to back in a player that does not skip it. It also explains why a part looks 36 milliseconds longer than its audio when you check the length in a file manager or a media library.

We repeated the test with the engine's arguments for each format, cutting 20 seconds out of the same 60 second tone. WAV and FLAC parts decoded to exactly 882000 samples, with no extra in either mode, because they store samples directly. OGG with `libvorbis -q:a 5` came out at 882000 normally and 882368 with trimming off, a few hundred samples of padding. M4A with `aac -b:a 192k` was the surprise: even with normal decoding the part came out at 882688 samples, 688 more than the 20 seconds we asked for, about 15.6 milliseconds, and 883712 with trimming off. So if exact length matters, WAV and FLAC are the only formats where the part is the length you asked for, and the lossy formats each add a little. If you want seamless parts, split a WAV or FLAC source and keep the parts in that format.

For listening, you will rarely notice. A lecture cut into chapters, a podcast cut into segments or a long recording cut into tracks all start with a blip of silence far shorter than a breath. It matters in three cases. First, back-to-back playback in a player or car stereo that does not read the gapless information, where you hear a small hole at each join. Second, loops: a part that is meant to repeat will stutter, because each repeat inserts the padding again. Third, anything that depends on exact length or timing, such as lining a part up against a transcript or a video, where a part reporting 36 milliseconds more than its audio throws the arithmetic off. For a handful of cuts nobody will hear it, which is why most people never find the cause.

Pick the approach that matches why you split. If you only need chapters to listen to, do nothing: the padding is tiny and players that read the gapless information skip it. If you need seamless parts, split a WAV or FLAC file with the [Audio Splitter](/audio-splitter), because those formats add no padding, and keep them as WAV or FLAC. Converting each part to MP3 afterwards brings the padding straight back, so convert only once, at the very end, and only the file you will actually distribute. If you plan to rejoin the parts, see [joining MP3 files without gaps](/blog/join-mp3-files-without-gaps), and do the joining on lossless parts instead of MP3 ones. If you only need to remove a section, the [Audio Trimmer](/trim-audio) cuts once and re-encodes once, so you get a single pass of padding, not one per part.