Naming & folders · How we test and maintain this guide
Separate by purpose before adding more categories
A useful folder layout answers three questions: which files came from the source, which files you are editing, and which files are ready to hand over. It does not need a deep tree for every genre or instrument. Start with one project folder and a few roles you can explain to yourself a month later.
TuneBundle prepares downloads, names and accompanying records; it does not scan your computer or create a library structure automatically. The layout below is a suggested local practice. Adapt it to your editor and storage setup, and test it on a copy of one small collection before moving a large existing library.
A four-part project layout
| Suggested folder | Keep here | Avoid |
|---|---|---|
| 01-source | Untouched downloaded ZIPs or original exports plus their CSV and JSON | Editing the only source copy |
| 02-working | Renamed, tagged or edited copies for the project | Assuming their hashes still match source records |
| 03-delivery | Only the files and notes intended for a recipient or player | Including private evidence or unused takes by accident |
| 04-records | A source map, decisions and permission references | Treating a title or generated CSV as a licence |
For example, a project folder could contain a dated export under 01-source and a clearly named working version under 02-working. Use a date that describes the export or your filing action, not a guessed creation date for the song. Avoid ambiguous names such as final-final when a short revision and purpose are clearer.
The source archive's tracks.csv and manifest.json belong with that archive. They describe the selection and prepared outputs from that run. If you later tag or convert a working copy, its current file hash may legitimately differ. Record the relationship instead of editing the source manifest to pretend the transformed file was the original export.
Bring a new export into the project
- Save the archive and verify that the browser reports a completed download.
- Keep the untouched archive in the source area. Extract a checking copy into a new folder.
- Compare selected audio entries with the CSV inside that archive, including sizes and hashes where needed.
- Listen to the relevant takes and record which ones belong in the working set.
- Copy the chosen files into the working area, retaining a mapping back to their source identifiers.
For a partial batch, do not infer completeness from a tidy folder name. In our controlled twenty-row example, twelve rows were ready but only ten were selected. The intended archive therefore had ten audio files plus two records. Carry that distinction into your source map so an intentionally omitted take is not later treated as a missing download.
When a later export contains overlapping titles, stage it separately first. Compare source IDs and file identity before combining directories. Automatic suffixes can prevent an immediate collision while still leaving you with confusing duplicates. A staged comparison is easier to reverse than an overwrite in the main project folder.
Create delivery from the working set
Build a separate delivery copy after naming, metadata and listening checks are complete. Include only the requested formats, tracks and recipient-facing notes. Source URLs, internal comments and rights correspondence may belong in your records rather than in a public archive. Review the CSV before sharing it because it can expose song titles and source links.
Test the delivery folder from the recipient's perspective. Open files from that folder, not from an editor session that still points to the working originals. Check the intended order, filenames and metadata in the destination application. If the project changes, create a distinguishable delivery revision rather than silently replacing an already handed-over set.
Our local filing experiment confirms a practical boundary: a renamed copy preserved the original file hash, while writing tags changed the hash without changing the decoded audio in that test. The folder roles make both outcomes understandable. The source stays a reference, and the working copy is allowed to evolve with a record of what changed.