Published by PitchChanger · Updated · How these guides are made
How to use this workflow
Name the before and after files
Keep the previous delivery unchanged. Start a new changelog entry with the old and new filenames, revision IDs and the date. State whether the new file replaces the complete delivery or supplies an alternative; two different arrangements are not automatically sequential fixes.
Record changes and check the saved revision
Describe each requested change separately. Add its source interval, actual operation and new output location if timing moved. Prepare the file, reopen it and inspect the changed area plus the beginning and ending. An intended change remains pending until you verify the downloaded result.
A three-revision changelog with calculated timing
This original worked example is a fictional revision history, not three exported or listened-to files. A 60-second rehearsal source becomes r01 with no trimming. Revision r02 removes the first 2 seconds. Revision r03 keeps the r02 boundaries but changes the encoding to a recipient-approved format. It does not claim an audible improvement.
An event at source 20 seconds belongs at 18 seconds in r02 and r03 because 20 − 2 = 18. A comment referring to r01 at 00:20 must not be copied to r02 at 00:20 without mapping it. These are exact arithmetic expectations before codec padding and file inspection, not measured durations.
Swipe or scroll sideways to read all columns.
| Revision | Change | Calculated timing | Comment location |
|---|---|---|---|
| r01 | Untrimmed source-derived copy | 60 s expected | Source event 20 s |
| r02 from r01 | Remove initial 2 s | 58 s expected | Same event 18 s |
| r03 from r02 | Encoding change only | Inspect actual saved duration | Event remains about 18 s |
Write the delta and its verification separately
A useful proposed entry is: “r02 replaces r01 for rehearsal. Removed source 00:00–00:02 to omit handling noise; musical event previously at 00:20 is expected at 00:18. Verification: pending check of saved r02 opening and event.” After listening, replace pending with the actual checked result and listening conditions. Do not present this example as a completed check.
If a change was deliberately omitted, say why beside the request. If another change accidentally moved the ending or removed a count-in, make that a new issue. Do not silently mark every request done because one export completed. The changelog is an external text record; PitchChanger does not create version history or track revision comments automatically.
Retain history when another revision arrives
Append the next revision instead of rewriting the old outcome. Link each new file to its immediate parent and keep a stable copy of the relevant notes. If you return to the original source, state that branch explicitly; an r04 built from the source may not contain the changes in r03.
Use descriptive change categories such as boundary, pitch, speed, mix or encoding. File hashes can help identify exact bytes when that matters, but identical musical content can have different metadata and different hashes. A hash does not prove that the requested edit was correct; the saved audio still needs the relevant checks.
Common questions
Do unchanged settings belong in every entry?
Keep a baseline settings record and note exceptions in each revision. Repeat any unchanged setting whose value is important to interpreting the change, such as speed remaining at 100%.
Does a new filename prove it is a new revision?
No. Identify the parent file and actual change, then inspect the saved result. A rename alone does not establish an audio edit.