Cut a ringtone, notification or alarm from any audio file, snap it to the beat so a repeat does not stutter, and set it to a loudness that holds up against the phone's own tones. Exports .m4r, .mp3 and WAV.
Initializing in your browser…
Convert between MP3, WAV, OGG, AAC, M4A and FLAC with a bitrate, sample rate, channel count and bit depth that all reach the encoder, and a panel that reports what was actually written.
Cut a region out of any audio file, exact to the sample and measured at zero milliseconds of error. Waveform handles, real keyboard shortcuts, click-free cut fades, and WAV or MP3 output that matches its extension.
Join clips end to end or stack them on one timeline, with an equal-power crossfade that holds the level through the join, BS.1770 loudness matching between files, and the merged result measured before you download it.
A quiet recording has a good hook in it, and you want a ringtone that loops cleanly and can actually be heard.
Input
quiet.wav (-32.3 LUFS) - snap to bars at 138 BPM - target -16 LUFS - ceiling -1 dBTP
Output
-16.00 LUFS measured, -1.00 dBTP, five whole bars long
The cut was already exact and still is; what was missing was the level. Without a target the same file exported at -32.70 LUFS, roughly sixteen decibels under where phone tones sit. The figures above come from measuring the downloaded file with ffmpeg. Snapping rebuilds the beat grid rigidly from the tempo and aligns it to the attacks, which landed within 2.8 ms of the real beats on a 138.000 BPM fixture, so the repeat comes round on the beat.
Cut a ringtone, a notification or an alarm, snap it to the beat so a repeat lands where it should, and set it to a loudness that holds its own against the tones your phone already has. The clip is measured before and after, so the level is a result rather than a hope, and the same measurement stops the old volume control from clipping.
Snap a five bar hook to the bar grid, apply a two second S-curve fade out, set -16 LUFS, and export as .m4r.
Cut a 0.8 second chime, add a 0.2 second fade out, and export as MP3 for Android.
Take the best part of a song, snap it to the bar so it loops without stuttering, and set it loud enough to hear from a pocket.
Cut a short alert tone, down to 0.3 seconds, which the old five second minimum made impossible.
Build an alarm at a slightly louder target with a gentle fade in, so it wakes you without startling.
Turn a quiet voice memo or field recording into a tone that is actually audible, with the peaks held under the ceiling.
The file is decoded with the Web Audio API and the cut is taken straight from the decoded samples. That part was already right and was measured before anything changed: asking for 10.0 to 20.0 seconds of a fixture carrying a different tone in each five second block returned exactly 10.0000 seconds, beginning on the correct tone. What was missing was everything around it.
A ringtone nobody hears is not a ringtone. There was no level control of any kind, so a quiet source made a quiet ringtone: a file measured at -32.30 LUFS exported at -32.70 LUFS, roughly sixteen decibels below where phone tones sit, which in a pocket is inaudible. The clip is now measured with the same ITU-R BS.1770-4 implementation the volume normalizer uses and given the gain that puts it on a target, -16 LUFS by default. The same fixture now exports at -16.00 LUFS, measured with ffmpeg on the downloaded file.
Pushing the other way had no protection either. The old Volume control went to 200 percent with nothing watching the peaks: a sine peaking at 0.900 exported at that setting with its third harmonic only 13.7 dB below the fundamental, which is hard clipping and audible as buzz. A true peak ceiling now sits on the output, held by a look-ahead limiter. The same request measures -1.00 dBTP with the third harmonic 128.3 dB down.
Snap to the beat is for the case a ringtone actually lives in, which is repeating. The tempo comes from the same engine as the BPM detector, and the grid is then rebuilt rigidly from that tempo and aligned to the attacks in the samples, because the beat peaks the detector picks are not evenly spaced: on a click track whose clicks sit at exactly k times 0.500000 seconds, consecutive detected beats were 0.556, 0.496, 0.471 and 0.561 seconds apart. The aligned grid also fixes a coarser problem: on a groove with a kick on the beat and a hat between the beats, the envelope grid had locked to the hats, a mean of 188 ms from the kicks and very nearly half a beat. Measured against two fixtures written at exactly 120.000 and 138.000 BPM, the aligned grid lands within 11.1 ms and 2.8 ms of the real beats, and both edges of the selection are placed on it with the length held to a whole number of beats or bars.
The waveform reads every channel rather than the first one. A test file with content only on the right channel used to draw as a completely blank panel, so there was nothing to aim at; it now draws. The wave is rendered once into an offscreen layer and only the playhead, the selection and the beat grid are repainted, instead of rescanning the audio on every animation frame.
Three clip kinds set sensible lengths: Ringtone 3 to 40 seconds, Notification 0.3 to 10, Alarm 5 to 40. The old build enforced a five second minimum on everything, which made the short message tones it advertised impossible to cut. Fades run 0 to 5 seconds at each end in any of five shapes, and the shape chosen is the function that multiplies the samples. Export writes a 192 kbps MP3 for Android and a 16-bit WAV, both encoded in the page with no WebAssembly download, or an .m4r for iPhone, which is AAC in an MP4 container and does need the ffmpeg core since nothing else in the browser can write AAC. The .m4r button disables past 40 seconds, which is Apple's limit for a custom tone.
Apple caps a custom .m4r tone at 40 seconds, and the iPhone button disables past that. Around 30 seconds is long enough to reach the phone. Notification tones are usually a second or two, and the Notification setting allows down to 0.3 seconds.
Because a phone plays your tone at the same system volume as its own, and its own are mastered to be heard. Without a target a quiet source stays quiet: a file measured at -32.30 LUFS exported at -32.70 LUFS, about sixteen decibels below where phone tones sit. With the target on, the same file exports at -16.00 LUFS, confirmed by measuring the download with ffmpeg.
It places both edges of the selection on a beat grid and holds the length to a whole number of beats or bars, so that when the ringtone repeats, the loop point lands on the beat instead of somewhere in the middle of one. The grid is rebuilt rigidly from the detected tempo and then aligned to the attacks in the audio, which on the test fixtures put it within 11 ms of the real beats.
Yes. Turn the loudness target off and a gain control in decibels appears. The true peak ceiling stays on either way, so pushing it hard limits the peaks rather than clipping them: the same request that used to export a sine with 13.7 dB of third harmonic now measures -1.00 dBTP with that harmonic 128 dB down.
Download the .m4r, connect the phone to a computer, and drag the file into the Tones section in Finder or iTunes. The file is AAC in an MP4 container, which is what iOS expects for a custom tone.
Because there never was one, despite older copy on this page saying so. Android accepts MP3 for ringtones, which is what the Android button writes, and a WAV export is there for anything that wants uncompressed audio.
Yes, that one path loads the ffmpeg WebAssembly core, because AAC is the one format the browser cannot write on its own. MP3 and WAV are encoded in the page and are immediate.
Audio is decoded and processed locally with the Web Audio API. Your files are never uploaded to a server.