How Lyricron Decodes Audio in Your Browser
Lyricron reads and decodes your audio locally with the Web Audio API, then plays it from memory on a precise clock. Here is what happens under the hood, including what changes when a file falls back to the browser’s media player.
The short version
When you drop a file in, the browser reads the raw bytes into memory.
Lyricron hands the audio to decodeAudioData, which produces an
AudioBuffer of sample data. Playback then reads samples from
that buffer using the Web Audio clock. The file never leaves the page.
File loading, step by step
-
The file input or drag-and-drop handler gives Lyricron a
Fileobject. -
Lyricron reads it into an
ArrayBufferwith the File API. -
For audio files, it calls
decodeAudioDataon anAudioContextto decode the compressed file into raw PCM samples. -
The decoded samples live in an
AudioBufferin memory, and playback uses anAudioBufferSourceNode. - For video files, or when decoding fails, Lyricron uses the browser’s built-in media element instead.
Why the clock matters for timing
The Web Audio API exposes a high-resolution clock,
AudioContext.currentTime, which is tied to the audio hardware.
Lyricron stamps each lyric using that clock, so a tap becomes a precise
timestamp instead of an approximate one based on
Date.now() or setTimeout.
That accuracy matters most when you are working at the edge of a syllable. A timestamp that is 30-50 ms off is often invisible in a casual player but obvious when you are trying to land exactly on the first consonant.
What happens with VBR files
Variable-bitrate files store audio in uneven chunks. Some players estimate playback position from the compressed stream and drift over time. Lyricron’s main audio path avoids that problem because the whole file is decoded first; playback then runs from the decoded samples, not from a bitrate estimate.
Drift can still appear if the lyrics were timed against a different master, a different edit, or a live version. It can also appear in the fallback media player path. The fix is the same either way: nudge the affected lines or retime the section. See how to fix out-of-sync lyrics.
Video files and stubborn formats
Video files are handled by the browser’s media element; Lyricron uses the
audio track and does not render the video. If an audio format cannot be
decoded with decodeAudioData, Lyricron falls back to the same
media-element path.
That fallback is not a bundled decoder. It is the browser’s native media player reading a local object URL. It keeps the privacy model intact, because nothing is uploaded, but timing may be less precise on variable-bitrate files. Lyricron shows a notice when this happens.
Offline-first storage
Your in-progress project auto-saves to the browser’s local storage, so a refresh does not cost you work. There is no server to sync to, no account to resume, and nothing stored anywhere but your device. The tradeoff is that clearing your browser data clears the project.
What never leaves your device
The audio file, the lyrics, and the timestamps stay local. There is no backend and no analytics. The only network request Lyricron makes is one you start yourself, such as an optional LRCLIB search for lyrics. The full rationale is in why a lyrics tool shouldn’t need your song files.
FAQ
Does Lyricron upload my audio?
No. The file is read and decoded in the browser.
Why does Lyricron use Web Audio instead of a normal audio element?
The Web Audio clock is more precise, which makes tap-to-time lyrics more accurate. Video and undecodable audio use the media element fallback.
Does the fallback use a different decoder?
No. It uses the browser’s built-in media player, not a bundled decoder.
Related guides
Time a track locally
Open Lyricron and see the decoded-audio workflow for yourself.