Playback speed and audio pitch
Playback speed can alter both duration and pitch, while time-scale processing changes duration while largely preserving the original pitch.
A 60-second passage played at 1.25× lasts 48 seconds. What happens to its pitch depends on how that speed change is produced.
If the original waveform is simply traversed faster, every oscillation also happens faster. A 440 Hz tone becomes 550 Hz. Pitch-preserving time-scale processing instead changes the duration while keeping that tone near 440 Hz.
| Speed factor | Duration of a 60 s passage | Tone with ordinary rate change | Tone with ideal pitch preservation |
|---|---|---|---|
| 0.8× | 75 s | 352 Hz | 440 Hz |
| 1.0× | 60 s | 440 Hz | 440 Hz |
| 1.25× | 48 s | 550 Hz | 440 Hz |
| 2.0× | 30 s | 880 Hz | 440 Hz |
These are mathematical values. A practical pitch-preserving processor can introduce artifacts whose character depends on the material and algorithm.
Compressing the entire time axis changes pitch
For ordinary rate change, the output samples a waveform described by y(t) = x(s × t), where s is the speed factor. At s = 1.25, a second of output covers 1.25 seconds of the source. The waveform's cycles are squeezed into less time.
The pitch change in semitones is 12 × log₂(s). At 1.25× it is approximately 3.863 semitones; at 2× it is one octave.
This can be implemented while still sending the device its normal output rate. The player computes a faster traversal into that fixed-rate output stream. Changing a file's declared sample rate without recalculating its samples is another way to change their interpretation in time.
Ordinary sample-rate conversion has a different goal: represent the same-duration waveform on another sample grid. Converting 44.1 kHz material correctly to 48 kHz preserves its duration and pitch.
Keeping local cycles while changing the sequence
One family of time-scale methods divides audio into overlapping windows, selects suitable positions in the input, and blends the windows at different spacing in the output. The waveform inside a window keeps its original local oscillations; the sequence advances through the programme at a new pace.
For an illustrative 1.25× process, input window starts can advance 12.5 ms for each 10 ms output advance. Over 48 seconds of output, those advances cover 60 seconds of source. The implementation searches for compatible waveforms near candidate joins, then blends the overlap to avoid abrupt discontinuities.
FFmpeg's atempo implementation uses WSOLA, a waveform-similarity overlap method. Other processors use frequency-domain methods such as phase vocoders. Their internal window and alignment choices are not specified by the speed factor alone.
Speech, sustained music and sharp attacks present different problems. A long tonal window gives useful periodic information; a short transient benefits from retaining its time shape. Independently choosing joins for left and right channels can disturb stereo relationships, so multichannel processing needs coordinated treatment.
The movie uses the same new clock
For faster video playback, picture presentation times must advance at the corresponding rate. The audio processor may need an internal lookahead or startup buffer, which the player must incorporate into its synchronization.
In an Emby app, a speed control therefore involves more than changing how many audio packets are fetched. The selected player has to produce the required audio, schedule pictures on the new timeline, and keep its buffer/clock accounting consistent. A voice that rises in pitch and a voice that stays natural can both accompany 1.25× playback; they reveal different signal processing.