A field recorder can record reliably only when the storage medium is supported by that specific recorder and can sustain the selected recording data rate; the recording format then defines the saved file structure and metadata. For uncompressed recording, storage demand rises with sample rate × stored bits per sample × channel count, so available recording time is estimated from usable capacity divided by that data rate.
Field-recording storage and format decision map
Separate three decisions: whether the card is compatible, how the audio file is structured, and how quickly the chosen recording settings consume storage.
1 · Card compatibility
2 · Recording format
bext) chunk when written by the recorder.3 · Storage planning
sample rate × bits per sample × channels ÷ 8 = bytes per second.usable bytes ÷ bytes per second.Keep the layers separate: recorder support controls media compatibility, recording settings control storage demand, and the file format controls file structure and workflow metadata.
The sections below move from the recorder-to-media-to-file relationship through card compatibility and format choice, then into storage estimation and preservation of original recordings.
Storage media and recording format describe different layers of the same recording path. The recorder writes a file in a supported format onto a supported physical medium.
The recorder-to-media-to-file relationship is shown below: capture and recording settings are turned into a file, and that file is written to supported storage.
A memory card is compatible only when all relevant media conditions match the recorder: card form factor, supported card family, capacity, required formatting or file system, and sustained write performance for the intended recording configuration.
A card with a higher capacity or faster advertised speed does not override an unsupported standard, capacity range, or formatting requirement.
Verify the complete set of conditions before a recording session; a card can satisfy one attribute and still be unsupported because another requirement is not met.
SD and microSD are physical form factors, while SDHC and SDXC are capacity-based SD card families. Compatibility therefore requires both the card's physical form and its standard to match the recorder.
Compatibility rule: physical fit is only one requirement. The recorder must also support the card family, capacity, formatting condition, and required write performance.
A field recorder can use a memory-card capacity only when it falls within the recorder's documented supported range. There is no single universal maximum that applies to every field recorder.
Recording duration is a separate calculation: once a card is supported, available time depends on its usable capacity and the selected recording data rate.
For continuous audio recording, sustained write capability matters more than a card's advertised read speed. The card must continuously accept data at least as fast as the field recorder produces it.
The required write rate rises when the recording data rate rises, including when sample rate, stored sample size, or channel count increases.
| Card speed attribute | What it describes | Why it matters to the recorder |
|---|---|---|
| Read speed | How quickly stored data can be retrieved from the card, such as during file transfer. | Useful for offloading files, but it does not establish whether recording can be sustained. |
| Sustained write behaviour | The card's ability to maintain write throughput while data is recorded continuously. | It must stay above the recorder's required recording data rate under the selected configuration. |
| Speed-class marking | A minimum write-performance class. For example, C10, U1, and V10 indicate 10 MB/s; U3 and V30 indicate 30 MB/s. | The marking is useful only when it satisfies the recorder's specified requirement; a higher class does not override other compatibility limits. |
| Recorder-specified requirement | The card type, speed class, performance condition, or tested-media guidance stated for a particular recorder. | This is the controlling compatibility condition for that recorder. |
Use the speed-class value as a minimum-performance indicator, then apply the recorder's own supported-media or approved-card guidance. A fast card is still unsuitable if its card family, capacity, or formatting condition is unsupported.
A recording file format defines how the saved audio file is structured, including the representation of audio data, channel organisation, and supported metadata. It does not define which memory card the recorder can use.
Format choice affects file handling and metadata exchange, but it is not a universal sound-quality ranking. With like-for-like audio settings, WAV and BWF can carry equivalent audio data while differing in workflow metadata.
BWF (Broadcast Wave Format) is a WAVE-compatible extension designed to carry additional broadcast and production metadata. It does not inherently increase audio quality over a WAV file recorded with the same audio settings.
The practical distinction is whether the workflow needs metadata that the recorder writes and the receiving system can use.
| Attribute | WAV | BWF | Field-recording implication |
|---|---|---|---|
| Audio structure | Uses the WAVE/RIFF file structure for audio data. | Retains the WAVE/RIFF audio structure. | With the same recording settings, the formats can carry equivalent audio samples. |
| Metadata capability | Can contain metadata in chunks supported by the writing and receiving software. | Adds the Broadcast Audio Extension (bext) metadata structure and can coexist with other supported WAVE metadata chunks. | BWF is useful when workflow metadata must travel with the file. |
| Broadcast Extension values | No BWF bext requirement. | The bext structure can carry fields such as description, originator, origination date/time, and a time reference when the recorder writes them. | Those values can help identify and align recordings in production systems that recognise them. |
| Interoperability | Depends on receiving systems supporting the WAVE file and the metadata actually used. | Also depends on receiving systems recognising the relevant BWF metadata. | Choose the format according to the complete recorder-to-post-production workflow, not the filename extension alone. |
Choose BWF when workflow metadata matters and both ends support it. Choose ordinary WAV when the required workflow does not depend on BWF-specific metadata; in either case, confirm the exact options implemented by the recorder.
File size and available recording time are controlled by the recording data rate and the card's usable capacity. At a fixed data rate, file size grows linearly with duration; at a fixed capacity, a higher data rate shortens available recording time.
| Recording variable | Value or condition | Storage effect | Planning implication |
|---|---|---|---|
| Sample rate | More samples stored per second for each channel. | With bit depth and channel count held constant, increasing sample rate increases the data rate and storage consumed per unit of time. | A higher sample rate requires more usable capacity for the same recording duration. |
| Stored sample size/bit depth | More data stored for each audio sample under the selected recording mode. | With sample rate and channel count held constant, increasing stored sample size increases the data rate and resulting file size. | A larger stored sample size consumes usable capacity faster under otherwise comparable conditions. |
| Channel count | More audio channels written to the recording file. | With the other recording settings held constant, increasing channel count increases the total data rate and storage demand. | A higher channel count reduces the recording duration available from the same usable capacity. |
| Duration | More time recorded with the same recording configuration. | At a constant data rate, file size increases in direct proportion to recording duration. | A longer session requires proportionally more storage when the recording configuration remains unchanged. |
| Usable card capacity | Storage space available to the field recorder after formatting, reserved space, existing files, and recorder-specific storage behaviour are accounted for. | At the same data rate, greater usable capacity provides more space for recorded data. | Recording-time estimates should use usable capacity rather than assuming all nominal card capacity is available. |
Uncompressed storage relationship
bytes/second = sample rate × stored bits/sample × channels ÷ 8
recording time = usable bytes ÷ bytes/second
These equations describe the audio payload for uncompressed PCM-style storage. Container headers, metadata, formatting, reserved space, existing files, and recorder file-splitting behaviour can reduce practical available time.
Increasing sample rate, stored sample size, or channel count while holding the other variables constant increases storage consumed per unit of time. Increasing usable capacity moves recording time in the opposite direction.
Sample rate, stored sample size, and channel count each scale storage demand directly for uncompressed audio when the other variables are held constant. Doubling one of those factors doubles the raw audio data rate.
These are storage relationships, not quality recommendations. The appropriate recording settings depend on the capture and workflow requirements, while this section only describes their effect on storage.
For the same sample rate, channel count, and duration, a recording that stores 32-bit floating-point samples uses a larger raw audio payload than packed 24-bit PCM.
24-bit PCM
3 bytes per sample per channel when 24-bit PCM is stored in packed 24-bit sample words.
Baseline for the like-for-like comparison.
32-bit float
4 bytes per stored sample per channel in the raw audio payload.
When compared with packed 24-bit PCM, that raw payload is 4/3 as large, or about 33.3% more, at the same sample rate, channel count, and duration.
Complete file sizes also include headers, metadata chunks, and recorder-specific file handling, so the exact total-file ratio can differ slightly from the raw-payload ratio. The comparison does not imply that one mode is universally the better recording choice.
Estimate recording time by dividing usable card capacity by the recording data rate after converting both to compatible units.
Illustrative result
About 57.9 hours at 48 kHz, 24-bit, two-channel uncompressed recording when 60 GB is genuinely usable.
The practical duration may be lower because of file-container overhead, formatting, reserved space, existing files, file splitting, or other recorder behaviour. Check the recorder's own remaining-time indication or documentation before relying on the estimate for a session.
File management for field recordings means keeping the original recording set identifiable and intact from the source card through a verified transfer and a separate backup.
Use a repeatable sequence so files, folders, identifiers, and metadata remain associated while the session moves away from removable capture media.
Do not reuse or reformat the source card until the transferred recording set has been verified and a separate backup exists.
Consistent folders, unique filenames, and preserved metadata make recordings easier to distinguish and retrieve across multiple sessions. A practical filename should identify the session without trying to duplicate every metadata field.
Illustrative filename anatomy
2026-10-21_SESSION03_FOREST-01.wav
The pattern is an example, not a required naming standard. The important properties are uniqueness, consistency, and traceability to the original recording.
Metadata carries information beyond the visible filename, and the fields available vary with the recorder and recording format. When organising copied recordings, preserve the original identifier and relevant recorder-generated metadata so the file remains traceable to its capture context.
Keep the source card unchanged while recordings are copied, verified, and backed up. Transfer, verification, and backup are separate preservation actions.
Preserve original files, identifiers, and relevant metadata together wherever later identification or retrieval depends on them.