> ## Content Index
> Fetch the complete content index at: https://izotoperx.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# iZotope RX 12 Batch Processing: A Safe Workflow
- URL: https://izotoperx.net/izotope-rx-batch-processing/
- Published: 2026-09-03T20:53:06.000Z
- Updated: 2026-09-05T20:32:43.000Z
- Description: A batch is safe only when the files share the same problem. Prove the chain on a pilot, write to a new destination and verify every output before delivery.
- Author: Brandon Hayes
- Tags: Workflow, RX 12, Getting Started

RX 12 Batch Processor runs the same processing chain across a group of audio files, then writes the results with your chosen naming and format settings. Prove those settings on a small pilot first: a detector that dulls one voice can dull every chapter in the queue.

The safe rule is simple: batch only files that share the same problem and delivery requirement. Build the chain on one representative source, run a two- or three-file pilot into a new folder, audit the results, then release the full queue.

## What RX Batch Processor does

The current [RX 12 Batch Processor documentation](https://docs.izotope.com/rx12/en/batch-processor.html?ref=izotoperx.net) describes three areas: Input holds files, Module Chain defines serial processing, and Output controls destination, naming and format. It can run alongside the Audio Editor, so the batch continues while other RX work remains available.

Batch Processor belongs to the standalone Audio Editor in [RX 12 Standard and Advanced](https://www.izotope.com/products/rx-advanced?tab=compare&ref=izotoperx.net). RX Elements does not include this Editor workflow. Individual modules still depend on your edition; having Batch Processor does not unlock Advanced-only tools.

Open it from Window → Batch Processor or use Cmd+B on macOS and Ctrl+B on Windows. Add individual files or drag folders into Input. RX displays channel count, bit depth, sample rate and duration; treat those columns as a preflight, not decoration.

A Batch Processor preset can save both Module Chain contents and output options. That makes recurring production efficient, but it also means an old destination, suffix or bit-depth choice can return with the processing chain. Review every field before Process.

## Batch only files that genuinely belong together

“All files in this folder” is not a processing criterion. Group by microphone, room, speaker or instrument, recording gain, noise behavior, channel layout, sample rate and destination. A learned noise profile from one air conditioner is not valid evidence for a street interview.

| Good batch group                                  | Split into separate jobs                                  |
| ------------------------------------------------- | --------------------------------------------------------- |
| Same narrator, microphone, booth and session gain | Different guests recorded on laptop, phone and studio mic |
| Sample library captured through one fixed chain   | Acoustic, electric and field samples in one folder        |
| Dialogue from one lav and one location            | Lav, boom and ADR mixed together                          |
| Homogeneous archival transfers from one setup     | Vinyl, cassette and digital errors combined               |
| Files sharing one delivery specification          | Archive masters, streaming files and review MP3s together |

When the source changes, make a separate batch and retune the settings. Save a distinct preset revision and choose a new destination. Reusing a chain does not make unrelated recordings acoustically equivalent.

## Nine steps for a safe RX batch

1. **Protect the masters.** Make an independent backup of the source audio and choose a new, empty output folder outside the input tree.
2. **Group matching files.** Batch only recordings that share capture conditions, defect and delivery requirement.
3. **Choose representative sources.** Include the worst defect, clean material, loud peaks, quiet detail and boundaries.
4. **Build the Module Chain.** Tune stages in the Editor, check their order and power controls, and compare complete results from the same unprocessed source at matched loudness.
5. **Preflight Input.** Check file count, paths, names, channels, bit depth, sample rate and duration; exclude earlier exports.
6. **Set protected Output.** Choose a separate folder, unique suffix or prefix, format, bit depth and one dither stage where required. Configure Resample in the chain only if conversion is needed.
7. **Run a small pilot.** Process two or three representative files with the proposed full-batch settings.
8. **Audit the pilot.** Reopen outputs, listen to clean and damaged passages, and verify names, duration, channels, sync, loudness and required metadata.
9. **Run and reconcile.** Process the approved group into a fresh destination, resolve failures, and match every input path to a valid output without reprocessing the pilot derivatives.

Do not skip the pilot because one file already sounded good. A small set exposes quiet/loud variation, longer duration, different boundaries and naming collisions before hundreds of derivatives exist.

## Build the Module Chain before opening the queue

Design the order on an independent source copy in the Audio Editor. Test De-clip only for actual clipping and impulse repair only for the clicks present; broad denoising need not be the first operation. Put delivery operations after the repairs. Compare complete chains from the same original state, because bypassing a module cannot undo an earlier render.

The [RX 12 Module Chain reference](https://docs.izotope.com/rx12/en/module-chain.html?ref=izotoperx.net) documents serial order, reordering, bypass and custom presets. The dedicated [RX Module Chain tutorial](https://izotoperx.net/izotope-rx-module-chain/) covers the harder editorial question: whether the sequence stays clean when several gentle processes accumulate.

Inside Batch Processor, recall the approved Module Chain preset. Use \[+\] to add a module, drag its panel to reorder it, use the power button to enable or disable it, and open View Module to inspect the settings for that particular chain step. Check its Frequency Selection Settings too: a saved restricted band is not a full-spectrum repair.

The current [preset and module-control documentation](https://docs.izotope.com/rx12/en/common-module-controls.html?ref=izotoperx.net) identifies an asterisk as unsaved preset changes; use Update Preset or Add Preset to retain them. Reopen the saved chain and inspect it before the pilot. Individual module footer Preview/Compare controls are unavailable inside Module Chain. Tune those modules in the Editor, then judge the complete chain through its actual output files.

## Preflight Input before processing

Use the Input columns to find outliers. A mono file among stereo files, 44.1 kHz sample among 48 kHz production audio or ten-minute chapter among short clips may be valid—but it deserves an explicit decision.

Count the inputs and keep a manifest with original path, filename, duration, channels, sample rate and intended output path. Dragged folders retain their folder structure under the selected destination. Exclude proxies, previous exports and unrelated media. Keep the destination outside the input tree so a later folder import cannot accidentally include your last batch.

Split out files that need a different learned noise profile or a local time selection. The [Spectral De-noise manual](https://docs.izotope.com/rx12/en/spectral-de-noise.html?ref=izotoperx.net) distinguishes a fixed learned profile from Adaptive mode, which follows incoming noise. A preset does not establish that one fixed profile fits every input. Learn from noise-only material, verify that profile in the recalled step, and test each source group; audition Adaptive mode separately if the noise changes. Use the [Editor, plug-in and Connect comparison](https://izotoperx.net/rx-editor-plugins-connect-workflow/) for repairs needing local or DAW-context judgment.

## Keep batch outputs separate from source masters

Use Choose folder… in Output to select a new, empty destination outside the source tree. The output ellipsis menu also offers Same as Original Location; do not use that route for this protected-copy workflow. Keep an independent backup of the masters. A separate filename is useful, but it is not a substitute for a recoverable source.

Enter a suffix such as `_rx-clean-v1` in Naming and select the After icon, or choose Before for a prefix. Check the resulting names in the pilot. A suffix cannot distinguish two inputs with the same basename if they resolve to the same output path. Preserve distinct source folders or split those inputs into separate destinations; do not assume an overwrite prompt will protect them.

Preserved folder structure does not replace a manifest. At the end, reconcile expected files against outputs and inspect any failure or duplicate instead of assuming a completed progress bar means complete delivery.

## Format, sample rate and bit depth are delivery decisions

The current RX 12 Batch Processor documentation lists WAVE, AIFF, FLAC, Ogg Vorbis and MP3\. Choose from the downstream specification: uncompressed PCM or lossless files for masters and editing, and lossy formats only when the deliverable explicitly requires them.

Do not make an MP3 the only archive of a repaired source. Preserve a PCM or lossless master, then make distribution copies from that approved file without running the cleanup chain again. In the [RX file-format documentation](https://docs.izotope.com/rx12/en/working-with-files.html?ref=izotoperx.net#export-options), WAV offers BWF header information and Preserve Non-Audio Data. Select the applicable options and verify required timestamps and identifiers on the actual outputs; do not assume every metadata field survives every format change.

For a required sample-rate change, add [Resample](https://docs.izotope.com/rx12/en/resample.html?ref=izotoperx.net) to the chain and set New sampling rate. Leave Change tag only off for real conversion: that option relabels the rate without resampling and changes playback speed and pitch. If delivery accepts the original rate, omit this conversion. Recheck peaks after resampling, since its filtering can alter them.

Channel layout needs a separate check. RX’s [Mixing module](https://docs.izotope.com/rx12/en/mixing.html?ref=izotoperx.net) controls contributions to the left and right outputs; centered or identical channels do not prove that the exported file has only one channel. If delivery requires a single-channel mono file, inspect the file’s actual channel count. If the chosen RX path still produces two channels, perform the explicit mono-file conversion in your delivery editor and verify again.

## Place dither at the required bit-depth reduction

iZotope’s [dithering guide](https://www.izotope.com/community/blog/what-is-dithering-in-audio?ref=izotoperx.net) recommends keeping floating-point intermediates where possible and applying dither when reducing to a lower fixed-point depth. A 32-bit floating-point export does not need dither. A processed file exported to 24-bit integer can involve a reduction from the higher internal working precision, even if its input also said 24-bit.

For an intermediate returning to editing or mastering, use 32-bit float if the next stage accepts it. If that stage requires 24-bit fixed point, consider the dither needed for that conversion now; “not the final master” is not a reason to ignore quantization. On final delivery to 24- or 16-bit, set the chosen depth and dither together after gain changes, resampling and other processing.

Use one dither stage for a given conversion. If you deliberately use RX’s [Dither module](https://docs.izotope.com/rx12/en/dither.html?ref=izotoperx.net) at the end of the chain, match its target depth to the export and disable additional output dither. Alternatively, leave a separate dither module out and use the output option. Avoid needless fixed-point intermediate exports, and record where dither was applied for the next editor.

## Run a pilot that can actually fail

Choose two or three files: the typical source, the noisiest or loudest source and one boundary case such as the quietest or longest. Process them to the protected output folder with the exact final naming and format policy.

Reopen the pilot derivatives in the Editor and compare them with the original files at matched loudness. Check the worst defect, clean passages, starts, ends, pauses, breaths, fades, transients and room tone. The [RX audition and History workflow](https://izotoperx.net/izotope-rx-selections-preview-compare-history/) explains fair comparisons while tuning. If the chain changes, rerun the pilot from the originals into another fresh destination; processing an already cleaned result applies the chain again.

Once the pilot passes, either exclude those original pilot inputs from the production queue and reconcile both output sets, or run the whole original group into a different empty folder. Keep one deliberate route for each expected output. Do not drag the cleaned pilot files back into Input or silently mix exports from different preset revisions.

## Podcast and audiobook batches

Long-form speech is tempting to batch because repetition is expensive. Group chapters by narrator, microphone and room. Use light defect repair, following the same source diagnosis as the [RX background-noise workflow](https://izotoperx.net/remove-background-noise-izotope-rx/), then set level and loudness only against the actual publisher or platform specification. There is no universal target for every delivery.

iZotope’s [RX 12 podcast and audiobook example](https://www.izotope.com/en/learn/fast-audio-cleanup?ref=izotoperx.net) combines Trim Silence and Dialogue Isolate in a chain, then discusses Leveler and Loudness Control. Trim Silence and Leveler require Advanced; Standard users should leave those stages out and handle any necessary pause edits or leveling in their existing editor. The example’s timing and loudness values are not universal delivery requirements.

The [Trim Silence manual](https://docs.izotope.com/rx12/en/trim-silence.html?ref=izotoperx.net) says it ignores the current selection and processes the entire file. It removes intervals and changes timing, so keep it out of picture-locked or otherwise synchronized work. For unsynchronized speech, audition chapter transitions, reverb tails and intentional pauses before batching. A quiet interval may still be part of the performance.

## Sample libraries and archival transfers

For sample libraries, consistency in naming, start/end boundaries, channels and sample rate can matter as much as denoise. Test transient-heavy and sustained samples separately. A chain approved on pads may soften drum attacks; one approved on one-shots may leave noise obvious in long decays.

For archival transfers, divide by medium and capture setup. Large clicks may require De-click before fine crackle; tape hum and broadband hiss need different profiles. Preserve the raw transfer and export restoration masters separately.

Wow & Flutter is specifically unavailable in the RX 12 Batch Processor documentation. Do not promise that module in an automated chain. Treat speed variation as a separate editor task and document it in the manifest.

## Keep repeated batches and machine load manageable

Batch Processor can run alongside the Editor, but a heavy chain and long files still consume CPU and memory. Run one approved group at a time if the machine needs room for other work. Finish or stop the current processing through the controls available in your RX window before changing a faulty chain; do not keep producing derivatives you already know are wrong.

After any interruption, reconcile files already written against the manifest. Keep uncertain or incomplete outputs apart, reopen them, and rerun only the required original inputs into a fresh destination. The existence of a filename does not prove that it contains a complete, usable result.

For light, normal and rescue groups, save distinct presets and output destinations. A Batch Processor preset contains output options as well as chain contents, so inspect both after recalling it. Keep a short note of the preset revision, source group, intended delivery and pilot results with the files.

## Why a completed batch can still be wrong

A progress bar proves that processing finished, not that the files meet editorial or technical requirements. A detector may have removed consonants, an output may be stereo instead of mono, a chapter may be shorter after silence trimming, or a suffix collision may have hidden a missing file.

Reconcile every input path to a readable output, then inspect duration, actual channel count/order, sample rate, bit depth, required metadata and any specified loudness or true-peak limits. Listen across the batch, including every outlier and rerun. For high-consequence delivery, complete the required full listening review; a small spot-check alone cannot certify every chapter.

If outputs sound unchanged, first check paths: are you playing the new files? Then inspect the recalled chain’s module power buttons, settings, order and frequency limits. Test a single known-defective source with one appropriate module. A clean source may legitimately need little change. File hashes can detect different bytes, but names, metadata or dither can change those bytes without proving that a repair succeeded.

## Final batch-processing quality gate

- Every input belongs to a homogeneous source and delivery group.
- The chain was approved manually on a representative file.
- Inputs were preflighted for count, name, channels, bit depth, sample rate and duration.
- Outputs go to a new protected destination with an unambiguous suffix or prefix.
- Format, sample rate, bit depth, dither and metadata follow the real delivery specification.
- A two- or three-file pilot passed listening and technical checks.
- The full output count reconciles with the manifest and all failures are resolved.
- Source masters remain intact and recoverable.

The [RX Workflows hub](https://izotoperx.net/rx-workflows/) connects Batch Processor to Module Chain, Editor versus plug-in decisions, DAW round trips and the rest of the production pipeline.

## Frequently asked questions

### How do I batch-process files in RX 12?

In RX 12 Standard or Advanced, open Window → Batch Processor or press Cmd+B/Ctrl+B. Add matching files, load an approved chain, choose a separate output folder and naming rule, then verify a small pilot before the full batch.

### Can RX apply several modules to every file?

Yes. The Module Chain area runs processing stages sequentially on each input. Tune and approve that order on a representative source before batching.

### Will RX overwrite my original files?

Do not rely on an automatic protection prompt. Use a new, empty output folder outside the source tree, check naming collisions, and keep an independent backup. Same as Original Location is available but is outside this protected-copy workflow.

### Which formats can RX 12 Batch Processor export?

The current documentation lists WAVE, AIFF, FLAC, Ogg Vorbis and MP3, with format-specific options.

### Should I enable dither in a batch?

Use dither for a required reduction to fixed-point depth, including a 24-bit intermediate when appropriate. A 32-bit floating-point export does not need it. Apply one dither stage per conversion, after other processing, and avoid needless fixed-point intermediate exports.

### Why did my batch make some files sound worse?

The group may not share one noise profile or damage pattern. Split files by microphone, room, gain and defect, lower the processing and rerun a representative pilot.

### Can I use Wow & Flutter in Batch Processor?

No. The current RX 12 Batch Processor documentation says Wow & Flutter is unavailable there; handle that repair separately in the Editor.

### Why do the outputs sound unchanged?

Confirm the output path, recalled settings, module power controls and any frequency restriction. Test one appropriate module on a known defect. Different file bytes alone do not establish audible repair.