Save and Resume a Music Tagging Session in Picard
At a glance
In Picard 3.0, sessions save the workspace state including file arrangement, manual edits, and album data but do not write tags to audio files. Sessions enable pausing and resuming tagging jobs without losing progress, ideal for complex or multi-album batches. Users should verify files and edits upon resuming, and sessions do not replace backing up audio files.
In this guide
In Picard 3.0, a session lets you save the current Picard workspace and reopen it later. It is separate from writing tags to audio files. Use a session when you want to pause a tagging job, keep your current file arrangement and visible manual edits, and return to the same work area before deciding what to write.
What a session is
A Picard session is a workspace snapshot, not an audio backup and not a promise that any tag has been written. It can preserve where items sit in Picard, including unclustered files, clusters, albums, specific tracks, and standalone recordings. It can also preserve manual metadata overrides, unmatched loaded albums, album expansion state, and a small set of core option values.
Session files use the .mbps.gz extension. They are compressed YAML files, and they store only user-visible tags rather than Picard internal tags. If the relevant session option is enabled, a session can also include MusicBrainz release data for loaded albums.
The practical point is simple: saving a session helps you resume the Picard job. Saving tags is the separate action that applies selected metadata changes to the audio files. If you have spent time matching a difficult compilation, correcting visible fields, or deciding which file belongs on which track, save the session before you close Picard or before you make another major change.
When to use sessions
Sessions are most useful when the work is too involved to finish in one pass. They fit jobs where you need to stop, compare decisions, or return later with a clearer head.
- Use a session when a batch contains several albums, loose tracks, or uncertain matches.
- Use a session after you have made manual placement decisions that would be annoying to repeat.
- Use a session before you begin a risky round of rearranging files inside the Picard workspace.
- Do not use a session as your only protection before large edits. It does not replace a separate backup of the source audio files.
If you are still preparing a messy folder, it can help to make the initial grouping understandable first. Our guide to clustering unmatched music files in Picard covers that earlier stage. A reopened session is easier to review when the clusters and album areas already reflect your reasoning.
Save your current work
Use the session commands from Picard’s File menu. A careful workflow is to create a named session once the job becomes complex, then save it again after important decisions.
- Load the files you want to tag. Do your normal review, clustering, lookup, matching, and manual editing.
- Use
File>Save Session As…the first time. This always prompts for a path, so you can choose where the session file will live. - Name it for the job. Include a collection name, artist, folder name, or date. For example,
incoming-rips-before-final-review.mbps.gzis more useful thansession1.mbps.gz. - Continue working. When you make more placement decisions or visible manual edits, use
File>Save Sessionto update the last used session file. - Before closing Picard, decide what needs saving. Saving the session preserves the workspace state. It still does not write tag changes to the audio files.
If there is no previous session path, Save Session prompts for one. Save Session As… always prompts for a path, which makes it useful for creating a checkpoint before a large set of changes.
New Session closes the current session and clears files, clusters, and albums from the workspace. If there is content to preserve, Picard prompts you to save. Starting a new session also clears the last used session path, so the next Save Session will ask where to save.
Resume later
To continue the job, open Picard and load the session file instead of rebuilding the workspace from the original folders.
- Open Picard 3.0.
- Use
File>Load Session…. - Select the saved
.mbps.gzfile. - Inspect the restored workspace. Look at the album area, clusters, track placements, and visible edits.
- Continue the job only after review. You can keep editing, save the session again, or separately decide whether to write tags.
If another session is active, Picard prompts you to save before loading the new one. Treat that prompt as a decision point. Loading a different session is not just opening a reference file. It changes the current workspace.
Recent Sessions can reopen one of the most recent session files. The recent list can be cleared. If you choose a recent session file that no longer exists, Picard notifies you and removes it from the list.
After restoring, do not assume that visible matches are still correct. The session brings back the workspace state, but it does not independently verify your choices. Check whether the restored arrangement still matches the files and the release you intended to tag.
Session versus saving tags
The safest way to think about Picard work is to separate three things: the source audio files, the Picard workspace, and the metadata written into files. A session concerns the workspace. Writing tags concerns the files.
| Action | What it is for | What to check |
|---|---|---|
| Save session | Pause and resume the Picard workspace | Session name, location, and whether recent edits are included |
| Load session | Restore a saved workspace state | File paths, placements, visible edits, and loaded albums |
| Save tags | Write selected metadata changes to audio files | Album match, track match, fields to be written, and file safety |
A good routine is to save a session before the final review, then inspect a smaller representative part of the job before writing tags broadly. If you are unsure about the outcome, work on copied test files rather than your only copy of the music.
Sessions also do not solve problems caused by deleted or moved source files. Because session files include absolute file paths, record where the audio files were when you saved the session. If you reorganize storage outside Picard, make a note of what changed before relying on an older session.
If your next task is confirming that files are matched to the intended tracks, see our guide to matching music files to album tracks in Picard. A saved session is most useful when the underlying matching decisions have already been checked.
Offline and restore options
Session restore can depend on how session-related options are configured. For an offline-oriented restore, verify the relevant session settings before saving the session, not after you need it.
- MusicBrainz data cache: If enabled, Picard includes release data for loaded albums in the saved session.
- No MusicBrainz requests on restore: When used with embedded data, Picard can restore from the cache and skip web requests.
- Missing embedded data: If network requests are disabled and an album has no embedded cache, that album cannot be loaded and its referenced files will not be automatically matched.
- No auto-matching on load: When enabled, files are placed as saved and unsaved edits are reapplied, rather than auto-matched by existing MusicBrainz identifiers during restore.
Only Rename Files, Move Files, and Don’t Write Tags are stored as core option values in the session. Other settings remain global to Picard. If a job depends on other preferences, record them separately in your own notes instead of assuming the session contains them.
Example workflow
Example: Lena has a folder called Incoming-Rips with three albums, several loose tracks, and one compilation that needs manual attention. She opens the folder in Picard, clusters the obvious albums, moves two files to the tracks she believes are correct, and edits a few visible title fields. She is not ready to write anything to the audio files.
She uses File > Save Session As… and names the file incoming-rips-before-write.mbps.gz. In a small note beside the project, she records the date, the source folder, and the reason for the checkpoint: “manual compilation placement not fully reviewed.”
The next day, she opens Picard, chooses File > Load Session…, and selects that file. She checks the compilation first, then reviews the other albums. Before writing tags, she asks three questions: Are the files still in the expected locations? Are the track placements still intentional? Are the visible manual edits still changes she wants?
This workflow keeps the purpose of the session clear. It helps Lena resume the tagging project. It does not prove that the matches are correct, and it does not replace keeping another copy of important source files before broad changes.
Check before batch edits
Before using a restored session for a large write operation, make a short inspection pass. Record what you observe, especially if the session was created days or weeks earlier.
- Confirm that the expected albums, clusters, standalone recordings, and unclustered files are present.
- Spot-check files that required manual placement. Write down which ones you checked.
- Review visible manual edits and remove any that were only temporary notes or experiments.
- Check the state of rename, move, and do-not-write behavior before writing tags.
- If files were moved outside Picard, record that and verify the restored paths before continuing.
- Create a new checkpoint with
Save Session As…before major rearrangements.
For any complex tagging project, create a named session once the workspace starts to represent real decisions. Reopen and inspect it before writing tags, and keep a separate backup plan for the audio files themselves.
Before starting a new tagging session, you can look up songs for your collection on Mp3Juice. Keep your permitted local files in stable folders so the saved Picard session can find them again.
