The short answer

A reliable podcast archive does more than keep a folder tidy. It preserves the original recording, separates working files from publishable exports, makes every version identifiable, and gives you evidence that a file survived storage or migration.

Use a four-layer file system:

  1. Source: untouched recordings, with no normalization or destructive editing.
  2. Edit project: session files and working audio used to produce the episode.
  3. Master: the approved stereo or mono program file used for delivery.
  4. Publication export: the encoded copy supplied to your hosting provider or RSS feed.

Give every episode one stable identifier and use it across all four layers. Keep the original file unchanged. Save loudness measurements and format details in a simple manifest. Back up the source and edit layers before you delete local working files.

This approach gives you a practical answer to three questions that are easy to confuse:

  • Which file is the source? The original recording, before editing.
  • Which file is the master? The approved program audio before delivery encoding.
  • Which file is published? The compressed copy attached to the episode.

1. Decide what the archive must preserve

Start with the episode lifecycle, not a particular storage product. A small team may be able to manage its entire archive locally, while a larger operation may need shared or remote storage. The folder structure and file identity should work regardless of where those files are stored.

For each episode, preserve these five items where practical:

  • The untouched source recording
  • The editing project and its dependent media
  • The approved master export
  • The publication export
  • A manifest recording technical details and checksums

Optional assets such as transcripts, show notes, music licenses, sponsorship approvals and room notes can be associated with the same episode identifier. They are useful, but they are not substitutes for the source audio or its technical record.

A practical rule is to preserve enough material to reproduce the published episode without contacting a guest or host. If a correction requires you to reopen the original conversation, reduce the noise floor again, replace an intro or change the ad break, you need the source and project—not merely the compressed MP3 or AAC file already in your feed.

Choose storage tiers by recovery cost

Think of storage as a set of recovery options rather than one folder.

Working storage is where recent source recordings and edit projects live while the episode is in production. Fast local storage is often useful here because editing benefits from responsive file access.

Primary archive holds approved masters, publication exports, manifests and important project files. It should have a clear backup arrangement rather than merely being a different folder on the same physical disk.

Cold or secondary storage can hold older sources and project files that are rarely opened. The trade-off is usually retrieval time rather than lower ownership: you are still responsible for finding, restoring and checking those files.

Do not choose tiers from the advertised capacity alone. Compare at least five operational questions:

  1. Can the service access, download or export every file you need?
  2. Can you restore a file without paying a separate recovery fee?
  3. Does the service support the metadata, checksums or versioning features your workflow relies on?
  4. What happens to the account if you stop paying?
  5. Can you migrate the archive without re-downloading every file one by one?

For a solo creator, the simplest arrangement is usually best: a disciplined working folder, a synchronized primary archive, and a separate backup. For a small team, shared naming, permissions and a manifest become more important than choosing a more elaborate folder tree.

2. Use one episode identifier across every file

Episode titles change. They may contain punctuation, accents or wording that is awkward in a URL. Build the filename from a durable episode identifier instead.

A simple convention is:

[SHOW]-[YEAR]-[NUMBER]-[ROLE]-[VERSION].[EXT]

For example:

field-notes-2026-014-master-v01.wav

field-notes-2026-014-publish-v01.mp3

field-notes-2026-014-source.wav

The elements do important jobs:

  • Show: identifies the series in a mixed archive.
  • Year and number: sort episodes into a predictable release order.
  • Role: separates source, working, master and publication files.
  • Version: records revision order without relying on “final,” “final2” or “really-final.”

If you publish a corrected version, increment the version and record the reason in the manifest. Do not silently overwrite the previous master.

Keep names simple and portable

Apple’s RSS technical requirements specify that filenames and URLs should use only ASCII characters from a-z, A-Z and 0-9. A conservative file naming approach is therefore to use lowercase letters, numbers and hyphens, with periods only for the extension.

Avoid:

  • Spaces
  • Curly quotation marks and apostrophes
  • Accented characters
  • Emoji
  • #, &, ? and other URL-sensitive symbols
  • Long descriptive titles embedded in the filename

Use the episode title in the manifest or metadata, where it belongs. The filename should identify the file, not repeat every publishing detail.

A useful structure is:

field-notes/
├── 2026/
│   └── 014/
│       ├── source/
│       │   └── field-notes-2026-014-source.wav
│       ├── project/
│       ├── master/
│       │   └── field-notes-2026-014-master-v01.wav
│       ├── publish/
│       │   └── field-notes-2026-014-publish-v01.mp3
│       └── manifest.csv
└── archive-index.csv
+```

This is an illustrative convention, not a tested storage implementation. Adjust the depth to your working style, but keep the roles and identifiers consistent.

## 3. Preserve source audio before editing

The source layer should be a faithful copy of what was recorded. If your recorder writes a WAV file, keep that file before applying gain, noise reduction, compression, fades or channel changes. If your workflow records separate tracks, preserve each original track and retain the information needed to identify the intended mix.

This matters because destructive processing can remove information that cannot be restored from the processed copy. A publication export may also have been encoded to a lower bit rate. Neither is a suitable substitute for the original recording.

A short intake routine prevents most archive problems:

1. Copy the new recording into the source folder without renaming it destructively or overwriting an existing file.
2. Confirm that the copy opens and that its duration is plausible.
3. Generate a checksum for the source.
4. Record its format, sample rate, bit depth and channel count.
5. Confirm that the backup copy is present and readable.
6. Only then begin or continue editing.

If a recording is split across several tracks, record their intended order and whether each file is raw, processed or already mixed. That note may be more valuable than trying to infer the sequence from filenames years later.

## 4. Turn loudness metadata into a recorded workflow

Loudness is a measurement, while normalization is a process that changes audio. Keep these separate in your documentation.

For every master and publication export, record the loudness value and related settings that your editing or encoding workflow applied. The exact measurement standard and target should come from your publishing requirements and production workflow; do not assume that one target fits every show and destination.

A usable manifest entry includes:

```text
episode_id: field-notes-2026-014
file_role: publish
file_name: field-notes-2026-014-publish-v01.mp3
format: MP3
sample_rate_hz: 44100
bitrate_kbps: 128
channels: mono
duration_seconds: 2348
integrated_loudness_lufs: [measured value]
true_peak_dbtp: [measured value]
checksum_sha256: [hash]

Use actual measured values in your own archive. The bracketed entries are placeholders, not recommended targets.

A repeatable loudness workflow is:

  1. Measure the finished master before delivery encoding.
  2. Decide whether the target requires gain adjustment, limiting or another processing step.
  3. Measure the processed master again and save the values with that version.
  4. Encode the publication file from the approved master.
  5. Decode or inspect the encoded output to verify that it matches the expected duration and channel configuration.
  6. Compare the output’s measured loudness with the master record.
  7. Keep both files rather than replacing the master with the compressed export.

This creates traceability: a future team member can tell which measurement belongs to which file version.

Delivery format is a separate decision

Apple Podcasts for Creators documents different formats for different delivery routes. Apple Podcasts Connect accepts WAV, FLAC and MP3 for subscriber audio. Its requirements specify that stereo sources should be retained for WAV and FLAC, with two identical channels used when no stereo source exists. For RSS feeds, Apple accepts MP3 or AAC and strongly recommends AAC in an MP4 container for efficient streaming and accurate seeking.

Those are platform facts, not a reason to compress every archived master. Keep an editable, high-quality master appropriate to your production chain, then create a publication export that matches the route through which the episode will be delivered.

Apple lists recommended MP3 ranges of 96–128 kbps for mono at 44.1 or 48 kHz, and 128–256 kbps for stereo at those sample rates. For RSS AAC or MP3 audio at 44.1 or 48 kHz, its listed ranges are 64–128 kbps for mono and 128–256 kbps for stereo. Check the current requirements before a release because distribution requirements can change.

5. Record technical details in a manifest

Folder names show what you meant to keep. A manifest proves what you actually stored.

A spreadsheet can be enough for a small archive. Useful columns include:

  • Episode identifier
  • Episode title
  • Record date
  • Release date
  • Source filename and checksum
  • Master filename and checksum
  • Publication filename and checksum
  • Format, sample rate, bit depth or bitrate, and channels
  • Loudness measurements
  • Processing notes
  • Backup locations
  • Modification history
  • Whether the episode came from one file or multiple source tracks

Store the manifest in both the primary archive and its backup. If the manifest is inside the folder it describes, a damaged drive or mistaken deletion can take the index along with the files.

For a larger catalog, a database may make searching easier, but keep the fields portable. A plain CSV or another open, readable format is often easier to inspect, migrate and recover than a proprietary catalog that only one application can interpret.

6. Use checksums without turning them into busywork

A checksum is a short fingerprint calculated from a file’s contents. If two calculations for the same file produce the same hash, you have evidence that the bytes match. If they differ, the file may have changed or been corrupted.

Use a strong checksum such as SHA-256 for archive verification. A practical routine is:

  • Generate a checksum when a source file enters the archive.
  • Generate checksums again after copying it to backup storage.
  • Generate checksums for masters and publication exports.
  • Recheck periodically and before high-risk moves or deletions.

For a modest episode archive, you can calculate hashes with a command-line utility or a reputable checksum tool. The important part is not the specific command; it is that the checksum values are written into the manifest and compared after transfer or restoration.

Checksums do not prove that the original recording is good. They only confirm that two copies are identical. That is still valuable because it detects many silent transfer errors and makes accidental changes visible.

Verify what was restored

After a restore test, open the restored file and confirm that it decodes. Then recalculate its checksum and compare it with the manifest. For a source file, also check that the duration and channel count match the record.

A successful “file found” message is not a complete restoration test. The file must be accessible, readable and unchanged.

7. Verify the archive before deleting anything

Do not make deletion part of the normal upload routine. Delete only after the episode is published and its replacement exists in the places you expect to need it.

Before removing a local file, confirm all of the following:

  1. The source recording and editing project are in the primary archive.
  2. The approved master and publication export are present.
  3. The manifest contains the correct filenames, technical details and checksums.
  4. A second copy exists in a backup or independently recoverable location.
  5. The episode has been tested from the distribution route.
  6. Any guest releases, music licenses or sponsor approvals needed later are retained.
  7. The files can be restored, not merely listed by the storage service.
  8. There is no reason to keep a superseded version only because its filename says “final.”

A useful deletion rule is: delete local working copies only after two recoverable copies exist; delete superseded versions only after the replacement and its manifest entry have been verified.

Keep superseded masters when a correction, sponsor dispute or rights question could make them valuable. Archive them with an incremented version number rather than overwriting them.

8. Test the workflow before you need it

A backup policy is a plan until you restore from it. Once or twice a year, select an older episode and perform a complete recovery check:

  1. Find the episode through the manifest.
  2. Retrieve its source, master and publication export.
  3. Compare checksums.
  4. Open each file and confirm that it decodes.
  5. Check the source and master duration and channel count.
  6. Verify the publication export against the intended delivery format.
  7. Confirm that the RSS enclosure still points to the intended audio file.

If the episode is hosted through a third-party provider, remember that episodes created from an RSS feed cannot be updated directly in Apple Podcasts Connect. Work with the hosting provider when the enclosure URL or audio needs to change.

Before a migration, export a complete manifest and test a representative sample from every tier and file role. Do not migrate only the publication MP3s; source recordings and project files are what make future edits and corrections possible.

For publishing QA, use the podcast episode publishing checklist after the audio workflow is in place. If automated enhancement is part of your process, the automatic enhancement versus manual editing guide can help separate recovery-friendly source handling from the final mix decision.

A practical archive policy for a solo creator

You do not need a complex content-management system to begin. Here is a workable starting policy:

  • Keep untouched sources, projects, masters, publication exports and manifests in separate role folders.
  • Use a stable episode ID and a predictable version suffix.
  • Store loudness measurements with the file they describe.
  • Maintain a primary archive plus a separate backup.
  • Verify checksums after transfers and during periodic restore tests.
  • Delete local files only when recoverable copies are proven to exist.

The goal is not perfect organization. It is the ability to answer, months later, “Which file is the source?”, “Which version was published?”, “What were its loudness settings?” and “Can I restore it?”

Frequently asked questions

Should I keep the source recording after publishing?\n

Yes, when practical. A compressed publication file is designed for distribution and may not contain the headroom or information needed to redo an edit. Keeping the source also protects you if an episode needs correction, a guest requests a change or you want to produce another version.

Is a WAV master always required?\n

No. The right master depends on your editing and delivery workflow. Preserve the highest-quality source you actually have, create an approved master suitable for your production process, and generate a separate publication export. Do not label a compressed file as a master merely because it is the largest version in the feed.

Are checksums necessary for a small podcast archive?\n

They are most valuable when files move among local drives, editing software, cloud storage and hosting providers. Even a small show benefits from checksums for source files and masters because they make copy integrity testable. The main requirement is that the algorithm and stored values are consistent across every verification.

What should happen when a published episode is corrected?\n

Create a new version, record its loudness measurements and checksum, update the publication enclosure through your hosting provider when necessary, and retain the prior master and publication export with a clear change note. Never rely on the word “final” to explain the difference.

Sources