Lossy encoders add samples at the start and the end of a file. Where the file declares how many, a player can remove them again and one track follows the next without a gap. This check reads those declarations out of the file. Nothing is uploaded, the file stays in the browser.
Choose an audio file
MP3, M4A/AAC, Opus, Ogg Vorbis, FLAC and WAV. Only the header is read, not the audio.
| Field | Value |
|---|
Encoders based on a transform need a run-up: the first block of output describes audio that starts before the file does, and the last block reaches past its end. Both ends are therefore filled with samples that are not music.
MP3 carries the numbers in the Info or Xing frame written by the encoder, together with the encoder name. On top of the delay stated there comes the delay of the decoder itself; this check adds 529 samples for it, which is what the measurement on the accompanying article showed.
In MP4 the start is described by the edit list, which moves the start of the track. Apple's iTunSMPB field states both ends in samples; where it is missing, only the track duration tells a player where to stop.
Opus states its pre-skip in the header, counted at 48 kHz, and the last page says how far the audio really reaches. RFC 7845 defines both, so gapless playback needs no extra field.
FLAC and WAV store the exact number of samples, so nothing is added and nothing has to be removed.
Sources: RFC 7845 · RFC 9639 · LAME tech FAQ
Only the headers are read, not the audio. What a particular player does with the fields is not checked here; the values show what it could do.