The model and worked examples

Start with a frame.
Keep every byte.

PCMspace estimates the data payload of one uncompressed, byte-aligned PCM stream from an entered format and duration. It is useful before a recording exists, or when checking the arithmetic behind a storage estimate. No audio file is opened, recorded, uploaded or inspected.

One complete frame contains all channels

In this model, each channel contributes one stored sample to every complete frame. If a channel sample occupies three bytes and there are two channels, a frame occupies six bytes. The entered rate is frames per second, equivalently samples per second for each channel. It is not multiplied by the channel count until calculating bytes per frame.

Microsoft's WAVEFORMATEX documentation describes PCM frame block alignment as channels times sample width divided by eight, and describes the rate for each channel. PCMspace uses that dimensional relation; it does not certify that an entered format is supported by a particular WAVE descriptor, recorder or player.

The supported stored widths are 8, 16, 24 and 32 bits, which occupy 1, 2, 3 and 4 bytes respectively. The form allows a positive whole sample rate up to 10,000,000 and a positive whole channel count up to 4,096. These are arithmetic boundaries, not a list of real hardware capabilities or recommended recording settings.

Worked example: 48 kHz, 24 stored bits, stereo

The default optional overhead field is blank. Therefore the tool knows the payload but leaves the combined nominal file size unavailable. It does not quietly add a header of an assumed size. If you explicitly enter 80 additional bytes for this hypothetical file, the combined arithmetic becomes 17,280,080 bytes. That entered 80 is your assumption, not a universal format requirement.

Stored width and valid signal precision

A sample can contain fewer valid signal bits than the space reserved for it. For example, a 24-bit signal may be held in a 32-bit stored container. Microsoft's extensible wave-format explanation distinguishes these two properties and describes byte-aligned storage containers.

To model that situation, select 32 stored bits and optionally enter 24 valid bits. The optional field explains the relationship but never reduces the bytes per frame. With two channels, the stored width now gives 2 × 32 ÷ 8 = 8 bytes per frame. At 48,000 Hz for 60 seconds, the payload is 2,880,000 × 8 = 23,040,000 bytes, or 23.04 MB. Selecting 24 stored bits instead gives the earlier 17,280,000 bytes. The tool does not convert between those representations.

Valid bits may be left unspecified. If supplied, they must be a positive whole number no greater than the selected stored width. Entering 25 valid bits with a 24-bit stored container is rejected. Channel count only multiplies storage here; it does not identify a speaker arrangement, channel order or recording quality.

A second independent payload example

For 44,100 Hz, 16 stored bits, two channels and 60 seconds, each frame uses four bytes. The frame count is 44,100 × 60 = 2,646,000. Payload bytes are 2,646,000 × 4 = 10,584,000 B. The byte rate is 176,400 B/s.

That is 10.584 MB or exactly 10.09368896484375 MiB. The on-page MiB view rounds to nine decimal places, but the exported exact byte value stays 10,584,000. This example provides a separate arithmetic check using a different sample rate and storage width; neither example is a recommendation to choose one format over another.

Why the calculator rounds up to complete frames

A requested duration can imply part of a frame. PCMspace's planning convention is to include enough whole frames to cover at least that duration. The frame count is the mathematical ceiling of rate times exact seconds. This is a stated convention of this calculator, not a claim about how every recorder handles a duration request.

An exact boundary does not gain an extra frame. At 10 Hz, 0.1 seconds means exactly one frame, while 0.100000000001 seconds needs two frames under this convention. Duration input is parsed as a decimal fraction and frame arithmetic uses exact integers, so binary floating-point noise does not turn the exact first case into the second. Zero duration gives zero frames and zero payload bytes.

Changing duration units without changing the request

The seconds, minutes and hours selector changes the display of the same physical duration. The calculator keeps its underlying exact fraction of a second until you edit the duration field. A decimal input may need a repeating expansion in another unit: 0.1 seconds is 1/600 of a minute.

The field displays up to twelve decimal places after a unit change. If that display rounds, a notice says that the original exact duration remains in use. Repeated unit changes therefore do not add a frame. Editing the duration field establishes a new exact request in the currently selected unit. Text and CSV exports include both the displayed input and the exact requested seconds as an integer or fraction, making the distinction visible.

The duration can be zero, but must otherwise be a nonnegative plain decimal with no more than twelve decimal places when directly entered. Commas, negative signs and exponent notation are rejected. The canonical limit is 1,000,000,000,000 seconds, with equivalent limits in other units. Those generous calculation limits do not assert that software, media or devices can produce or hold the result.

Decimal and binary unit views

One byte is eight bits. In the decimal views, kB, MB and GB divide bytes by 1,000, 1,000,000 and 1,000,000,000. In the binary views, KiB, MiB and GiB divide by 1,024, 1,048,576 and 1,073,741,824. The NIST binary-prefix explanation distinguishes these units.

The exact byte count is the common reference for every view. Rounded display figures are never multiplied back into a payload or used to decide whether a field value has been exceeded. Large frame and byte counts stay as exact integers, including values beyond the exact integer range of ordinary JavaScript numbers. Exports keep full decimal byte strings rather than silently converting them to scientific notation.

Payload is not the complete file or allocated disk space

The optional additional-bytes field is for an explicitly supplied count of non-payload data: for example, known headers, metadata and padding for the case you are modelling. It accepts whole bytes from zero through 10³⁰. A blank field means unknown, so combined bytes remain unavailable. Entering zero means you explicitly intend no added bytes. Additional bytes are added once to this one payload.

For a zero-duration case, entering 80 additional bytes gives zero payload plus 80 entered bytes, a combined nominal value of 80. Leaving that field blank instead leaves combined size unknown. Neither result claims that an actual empty audio file has a particular valid structure.

Microsoft's RIFF overview describes separate chunks, size fields and alignment padding. This is why PCMspace does not assume every WAV has a 44-byte overhead. It does not parse a container, calculate every chunk, validate an entered overhead or predict filesystem allocation units, project caches or backups.

The narrow unsigned 32-bit field check

The result compares the payload byte count with 4,294,967,295, the maximum value of one unsigned 32-bit scalar field. A payload at that value is within that scalar range; a payload of 4,294,967,296 exceeds it. A within-range result is deliberately not a complete RIFF/WAVE compatibility pass: overall size, other chunks, headers, padding and application constraints still matter.

The EBU RF64 format-design specification describes extended size fields for large audio containers. It provides context for the limitation, not proof that a particular recorder or player supports that format. PCMspace does not choose or migrate a file format.

Keep a local plan with the assumptions

Calculate a valid result before using Save text, Save CSV or Copy plan. The exports preserve sample rate, stored and optional valid bits, channels, exact requested and covered duration, frame count, byte rates, exact payload and overhead state. They include the frame-ceiling convention and the narrow scope of the field check.

Any edit invalidates the old result and disables export buttons until recalculation. Restore example returns to 48,000 Hz, 24 stored bits, two channels and one minute, with valid bits and overhead unspecified. Download generation and arithmetic run locally. There is no audio upload, microphone access, account or persistent project storage. Return to PCMspace or use the shared contact inbox for a reproducible calculation correction.