Can you trim an MP3 to the exact millisecond?
Short answer: yes, if you type the times and export WAV. We typed start and end times into this site's audio cutter and read back which samples each clip contained. In all 12 cuts on a 44.1 kHz WAV (10 typed, 2 dragged, on a desktop and a phone-sized screen), the clip started on exactly the sample we expected, 0 samples off, and had exactly the expected length.
Two things moved a trim by 1,105 samples (25.1 ms at 44.1 kHz) in our tests:
- Exporting MP3. The MP3 encoder puts 25.1 ms of silence in front of the clip, so everything plays 25.1 ms late.
- Opening an MP3 that has no LAME header, such as an MP3 saved by this cutter. Chrome's decoder keeps the encoder's silence at the start, so the cut lands 25.1 ms earlier in the music than the time you typed. An MP3 with the header was trimmed correctly.
To trim an MP3 precisely: open the audio cutter, type the times in the Start and End boxes instead of dragging, choose WAV (16-bit PCM) under Export format, and cut from your original file.
What "precise" means for an audio file
Digital audio is a row of samples. At 44.1 kHz there are 44,100 per second, so one sample lasts about 0.023 ms. A trimmer turns the time you choose into a sample number and keeps the samples between the two numbers.
On this site the time boxes take milliseconds. One millisecond is 44.1 samples, so a typed time can land on roughly every 44th sample, and the cut starts on the sample nearest that time. Anything past three decimals is rounded: we typed 7.0005 and the box changed it to 7.001.
Precision can go wrong in three places: the time you set may not be the time used, the tool may read your file with a shift, and the saved file may add something of its own. We tested each one.
How we tested
- Real tool, real browser. Playwright drove Chromium 153 on a local copy of this site's cutter page, once with a desktop window and once with a Pixel 5 phone profile. It opened each file, typed times into the Start and End boxes, pressed Download and saved what came out. Firefox and Safari were not tested.
- A file where every sample carries its own number. We built a 60 s, 44.1 kHz, 16-bit stereo WAV whose left and right values together spell out each sample's position. Any clip cut from it tells you exactly which samples it kept, even after the ±1 rounding the tool applies. The idea of marking the audio so you can see which samples a selection really holds comes from a proposal page on the old Audacity Wiki (archived snapshot of 2022-11-12). We ran our own version of it on our own tool.
- A file with clicks at known times. For MP3s and a 48 kHz file, where sample numbers do not survive, we used 60 s of silence with short noise bursts at known times (1.0000 s, 3.0003 s, 5.0006 s and so on). We found each burst in the output by cross-correlation and compared where it was with where it should be if the cut began exactly at the typed time.
- MP3 sources: the same click file encoded at 128 kbps two ways: by this site's own MP3 encoder (lamejs), which writes no LAME header, and by FFmpeg 4.4.2 with libmp3lame, which does. FFprobe reports a start time of 0.000000 s for the first and 0.025057 s for the second.
- MP3 exports were decoded twice, with FFmpeg 4.4.2 and with Chromium's own decoder (the one browsers use for playback). Both gave the same results.
Typed times on a WAV: which samples came out
| You type | Box shows | First sample expected | First sample in clip | Length expected | Length in clip |
|---|---|---|---|---|---|
| 12.345 to 16.789 | 12.345 / 16.789 | 544,415 | 544,415 | 195,980 | 195,980 |
| 0.001 to 0.5 | 0.001 / 0.500 | 44 | 44 | 22,006 | 22,006 |
| 7.0005 to 9 | 7.001 / 9.000 | 308,744 | 308,744 | 88,156 | 88,156 |
| 33.3333 to 35 | 33.333 / 35.000 | 1,469,985 | 1,469,985 | 73,515 | 73,515 |
| 59.5 to 60 (file end) | 59.500 / 60.000 | 2,623,950 | 2,623,950 | 22,050 | 22,050 |
| Drag, desktop | 22.494 / 40.000 | 991,985 | 991,985 | 772,015 | 772,015 |
| Drag, phone size | 26.707 / 40.000 | 1,177,779 | 1,177,779 | 586,221 | 586,221 |
The last row of typed cuts ended on sample 2,645,999, the final sample of the file, so trimming to the very end loses nothing.
Dragging a handle was just as exact about the time it showed, but you cannot choose that time finely. With a 60 s file, one pixel of the waveform was 67 ms on our 890-pixel desktop waveform and 181 ms on the 331-pixel phone waveform. Drag to get close, then type the exact value.
MP3 in, MP3 out: where the 25 ms shifts come from
Same cut (12.345 s to 18.345 s) on the click file in four versions. A positive number means the sound in the clip sits later than it should, measured in samples at 44.1 kHz.
| Source file | Export WAV | Export MP3 128 kbps |
|---|---|---|
| WAV, 44.1 kHz | 0.01 | 1,105 |
| WAV, 48 kHz | 0.01 | 1,105 |
| MP3 with LAME header (FFmpeg) | 0.01 | 1,104.98 |
| MP3 without LAME header (this site's encoder) | 1,104.98 | 2,210 |
| Same, both times typed 0.025 s later | 2.98 | not tested |
The 48 kHz file was converted to 44.1 kHz when the page opened it, and the cut still landed within 0.01 samples of the typed time. A different sample rate did not cost any precision.
MP3 export added 1,105 samples of silence at the start every time, whatever the source. The MP3 clip was also 1,512 samples longer than the 264,600 we asked for. The same 1,105-sample delay showed up in our test of MP3 quality loss, where it built up with every re-cut.
The MP3 without a LAME header was opened with the encoder's 1,105 samples still at the front: Chromium decoded it as 2,647,296 samples instead of 2,646,000. Every position in the file was pushed 25.1 ms back, so a cut typed at 12.345 s started at 12.320 s of music. The MP3 with a header was opened at exactly 2,646,000 samples and cut correctly. Exporting the headerless file as MP3 stacked both shifts to 2,210 samples.
Typing both times 0.025 s later fixed the headerless MP3 to within 2.98 samples (under 0.1 ms). It works because the shift is a fixed 1,105 samples, the same in every clip we measured.
How to trim an MP3 to the exact point
- Start from the original file, not from a clip you already cut and saved as MP3. Clips saved as MP3 by this cutter are the headerless kind.
- Find the spot by ear with Play region, drag the handles close, then type the final times in the Start and End boxes. Three decimals is the finest step.
- Export WAV when the exact start matters, for example for a clip that has to line up with something else. Nothing is added before or after the samples you chose.
- If you need an MP3 file, expect 25.1 ms of silence at its start. That is fine for a ringtone or a clip to share. If you must cut from a headerless MP3, type both times 0.025 s later.
Questions
How do I know if my MP3 has a LAME header?
Run ffprobe yourfile.mp3 and look at start: in the Duration line. In our test the file with a header showed start: 0.025057 and the one without showed start: 0.000000.
Is trimming less precise on a phone?
Not when you type the times. The phone-size profile kept exactly the same samples as the desktop in every typed cut. Dragging is coarser because the waveform is narrower: 181 ms per pixel against 67 ms on desktop for a 60 s file.
Does a 48 kHz file lose precision?
No. The cutter converts it to 44.1 kHz and cuts on that grid. In our test the cut was 0.01 samples from the typed time, the same as for a 44.1 kHz file.