![\"Sample](\"/assets/img/articles/sample-rate-bit-depth.svg\")
Sample rate and bit depth describe different parts of a digital recording. Sample rate counts time positions per second. Bit depth describes how sample values are represented. A setting of 48 kHz and 24-bit therefore does not mean twenty-four samples or a maximum tone frequency of 48 kHz.
\nChoose these settings for the source, processing path and delivery requirements. The Audio File Size Calculator can show their storage cost, but a larger byte count is not evidence that the recording contains more useful musical information.
\nAt 48,000 samples per second, successive sample frames are about 20.833 microseconds apart. At 96,000 they are about 10.417 microseconds apart. Each frame contains one sample per channel, so stereo doubles the stored sample count without changing the spacing in time.
\nFor integer PCM, bit depth determines the available code values. Sixteen bits provide 65,536 codes; twenty-four bits provide 16,777,216. These values describe amplitude encoding. They do not count musical pitches, volume-knob positions or separate instruments.
\nKeep the concepts separate when reading an export dialog. Changing stereo to mono alters the channel count. Changing 44.1 to 48 kHz alters the sampling rate. Changing 16-bit integer to 24-bit integer alters the sample representation. Each can change file size for a different reason.
\nThe theoretical Nyquist boundary is half the sample rate. At 44.1 kHz it is 22.05 kHz; at 48 kHz it is 24 kHz. Real systems need filtering and a transition region rather than treating the boundary itself as an ordinary usable audio frequency. Audacity’s sample-rate reference explains the distinction between sampling rate and practical bandwidth.
\nA low musical fundamental does not imply that a low recording sample rate captures its entire sound. The fundamental is one component. The instrument’s overtones and attack can extend much higher. Compare the wanted signal bandwidth with the recording path, rather than choosing a sample rate from the lowest note in the part.
\nRaising a file’s sample rate later does not reveal frequencies that were never captured. Proper sample-rate conversion creates a representation on the new time grid while controlling unwanted spectral effects. It is different from simply changing the rate label and playing the existing samples faster.
\nFor a concrete distinction, reading 44,100 samples at 48,000 samples per second shortens their duration to 0.91875 seconds. If that is a playback-rate change rather than proper conversion, it also raises pitch by about 1.467 semitones. The loop-tempo guide explains this time-and-pitch relationship.
\nAn integer audio format has a finite set of amplitude codes. Quantization maps the signal into those codes. More bits allow finer steps over the encoded range; they do not automatically make the recording louder or improve the microphone, room or performance.
\nFor the same full-scale range, adding one integer bit doubles the number of available codes. Moving from 16 to 24 bits adds eight bits and increases the number of codes by 256. Storage rises by a factor of 1.5 when moving from two to three packed bytes per sample, rather than by 256.
\nAudacity’s bit-depth reference describes amplitude precision, quantization error and the difference between integer and floating-point working formats. The nominal file format also does not establish the effective performance of the analogue converter. Noise and distortion elsewhere in the recording chain can dominate.
\nDo not use bit depth as permission to record an overloaded input. Clipping in a microphone preamp or converter has already changed the waveform before a later file conversion can help. Keep the original recording intact when evaluating a problem, and inspect gain settings throughout the capture path.
\nBoth formats use four stored bytes per sample, but they allocate those bits differently. Floating point uses a significand and exponent. It can represent values outside the usual normalized −1 to +1 range used for audio processing; that does not give every value the precision of a 32-bit integer.
\nFloating-point processing is useful when intermediate operations change level. A signal that exceeds a normalized output range within a floating-point path may be reduced before conversion to a limited output format. That possibility does not repair analogue clipping or guarantee that every plugin, interface and export stage preserves the over-range signal.
\nTreat recording format, internal processing format and delivery format as separate checkpoints. A program may process internally in floating point even when the imported recording is 16-bit integer. Exporting the original recording as float does not retroactively change how the source was captured.
\nWhen exporting a processed signal to a lower integer bit depth, dither can decorrelate quantization error. It adds a small noise signal for a defined technical purpose. It is not a noise-removal effect, a way to recover clipped peaks or a requirement to make every unchanged copy larger.
\nUse the editor’s documented export options when the workflow reduces integer precision. Avoid unnecessary repeated reductions during intermediate processing. Audacity’s dither documentation explains why ordinary rounding can create signal-related error and how dither changes that error’s character.
\nKeep the delivery requirement in view. If a collaborator asks for 24-bit uncompressed stems, sending a different format because its numbers look larger can create extra work. If a final destination requires 16-bit integer, keep an appropriate working master and make that delivery conversion intentionally.
\nAt 48 kHz, packed 24-bit stereo uses 288,000 audio bytes per second. Thirty minutes produces 518,400,000 bytes. Keeping the duration and channels fixed while moving to 96 kHz doubles that payload to 1,036,800,000 bytes. Switching the first example to 32-bit float instead produces 691,200,000 bytes.
\nFor the first result: 48,000 × 3 bytes × 2 channels × 1,800 seconds = 518,400,000 audio bytes.
These calculations establish a storage difference. They do not establish which setting sounds better for a particular source or processing chain. Use the stem-storage guide to include every file in a multitrack export, and leave room for the rest of the session rather than budgeting sample payload alone.
\nBefore recording, confirm the interface and session rate, the intended recording representation and the recipient’s delivery specification. Make a short test, play it back, inspect its properties and check levels. Resolve format mismatches during that test, while changing a setting is cheaper than repeating a performance.
", "license": "Content © Yunus Emre Vurgun. Drafted with AI assistance, then reviewed, corrected and published by the developer. Quote with attribution and a link to https://musics.name/articles/sample-rate-vs-bit-depth-recording/; do not republish whole articles without permission.", "provenance": { "drafted": "AI-assisted, against a written house style", "reviewed": "Reviewed, corrected and published by Yunus Emre Vurgun", "publisher": "Yunus Emre Vurgun", "site_developer": "Yunus Emre Vurgun", "disclosure": "https://musics.name/colophon/#how-articles-are-written" }, "source": { "file": "content/articles/sample-rate-vs-bit-depth-recording.md", "syntax": "Markdown with YAML-ish front matter", "published": "2026-10-20", "updated": "2026-10-20", "contributions": "Open an issue or send a correction through https://yunusemrevurgun.com/contact" } }