I was recently asked to deliver mixes at -6dB peak. I don’t really mix to anything, so instead I’m making an extra export from Ardour, normalizing peak to -6dB. My export window has two tabs, the default format and the -6dB format:
Is this meant to be this way? I’d understand that the revision number refers to the revision of the mix; once I made a new revision of the mix I might export it in N formats, but it’s still revision of the mix. So the revision number should be independent of the format; in other words it should be shared between the tabs. Or am I thinking about it incorrectly?
Matches my thinking, surprised I haven’t noticed this yet, but I am not really exporting multiple copies at once myself. Can you report this at tracker.ardour.org? Sad to say you will need a new account there as it isn’t tied to the forums at this time. Otherwise it may get lost here on the forums.
Hi,
i’m afraid that this is a more complex issue than it seems.
In this specific case you expect the revision count to be synchronized but that may not necessarily be the case in every situation. For example one may want to add another revision to format 1 only.
Judging from the screenshots you provided, you never actually did an export of *_r11 otherwise there should be a warning message in the bottom left corner stating that one or more files would be overwritten. This warning message only disappears when all selected export formats are configured to produce a file with a distinct not already existing name. In that case it would remain as long as you haven’t changed both rev counts.
On a side note:
I don’t know where the requirement of the -6dB peak level version stems from. I imagine it to be some sort of mastering service.
If this is the case, it is a matter of reducing (or raising) the overall level to meet this requirement (which btw could easily be done on the mastering service side). That would ensure that both versions your original mixdown and the -6dB one are dynamically exactly the same.
If your original mixdown is hotter than -6dB peak level the normalized version (if i understand this corrrectly) will retain the overall loudness by automatically limiting the peaks. The two versions are dynamically different now.
Thanks for thinking of various possibilities. To address some of your points - I don’t keep files in the export folder. Immediately after exporting, I move files out a different directory tree, where I keep my prints and past versions. That’s the first reason the warning doesn’t help me. The second reason why the warning doesn’t help me is that it only appears in the tab where you haven’t updated the revision number.
It’s interesting about the per-format revision counts. Is this what you do? What’s the thinking behind the per-format counts? Would you have then n+1 revisions counters to consider? N revision counters each per format and one more revision counter for the mixing work?
Yeah, that’s the thing, a user can do whatever he likes with files in the filesystem: move them around, delete or rename them.
Those fields and checkboxes in the export dialog are just little helpers for a possible naming scheme. One can ditch them entirely (unchecking “session name” and “timespan”) and use the freeform field for whatever cryptic (or not) naming scheme one wants to use.
Scenario:
I mix a song and when i feel i’m near the finishing line do an export of it as mp3 to reference listen to it in a playlist of other mp3s in a casual context (in a car, on the boom box in the kitchen while doing the dishes). After three revisions i feel confident to share my mix with my {clients, colaborators, whomever}. I still want those mp3s for reference listening and add another export format (likely lossless) to the export dialog. I 'd certainly not want ardour to sync the revision count of my wav export with the mp3 one. It should be *_r1.wav when i send it out and go in the “public” revision cycle.
I would be the exact opposite actually. Anyone can take that r1 file and make an r1.mp3 and that would add to confusion. Whereas having the .wav labeled as r3 doesn’t really hurt anything and clearly identifies that it came after r1 and r2 of the MP3s.
If I am sending out the file publicly I am likely not adding a revision number at all, and manually naming the file anyways.
That might be in this case. I’ve never used “normalize peak” in an export. However, if you use normalization to a certain loudness level and your mix is quieter like the target level you get peak limiting per default or your mix is likely to clip. This process is still called “normalization”.
Well, anyone can take the file “SomeArtist-SomeSong_r3.wav” and make it “SomeArtist-SomeSong_r3.mp3” too. That would be ludicrous regardless of the revision number, wouldn’t it?
The only reason i made up this scenario was to give a hint why a user may not want the revision count between two (or more?) formats to be synced automatically.
Not really as that would mean both are files made off the same revision of the mix.
Well, the process of applying the gain is called normalization. But the clipping that happens (As generally the export normalization is applied after any processing so there isn’t any compression aspect to it in Ardour currently) as a result of this would be a side effect indicative of problems in the mix to be addressed (And thus new revisions to be made).
I really do not understand what your argument is (for).
Again, the hypothetical “me” of my scenario has three mp3 files in his export folder (SomeArtist-SomeSong_{r1,r2,r3}.mp3 when he decides to add another format to enter another revision cycle in parallel. Since he has made some changes after the last export, he now exports “SomeArtist-SomeSong_r4.mp3” alongside the newly added lossless format he wants to share with whomever, prepared to do another round of changes due to feedback. Why should he not want to label that file “SomeArtist-SomeSong_r1.wav”? And who is that “anyone” who takes that file and makes an mp3 out of it?
I do not think that is true. If you use one of the predefined templates for streaming platforms peaks will be limited if necessary. The same goes for the normalization scripts of the streaming platforms themselves.
I am not saying someone couldn’t, I will argue they shouldn’t though.
If you are working collaboratively with anyone and sending files out to anyone it is important that people understand that they are, or are not, on the most recent revision of a mix. So if you are working on an album for a band and send it to them to listen to, or to your bandmates, or whoever, and they say they are on r1 of a wav file, or r3 on an mp3, those shouldn’t mean the same thing as it can cause a tremendous amount of confusion and you may be listening to feedback on things you already addressed in a more recent mix, but because there are a half dozen different revision numbers for different formats that can be pointed to the same mix, it is very confusing.
The revision, as mentioned in the export dialog, should be about the revision of the mix, not the revision of the file format necessarily. Even if it becomes revision of the file format, it becomes a both/and instead of either/or, so that you are always incrementing, and the highest revision number is always the latest.
Otherwise you get confusion if you work with anyone else.
You are correct, I had forgotten that there is some limited peak limiting available for export, though you would always be better off addressing that in the mastering stage instead of the export stage.
Depends. You will need a lot of knowledge and put in the time to be better than what Ardour does during export. Particularly if you need to address different streaming constraints with different specs, you’d have to do this 3 or 4 times manually.
and yes, I agree that the revision should reference the “current mix” (not current export).
It should be increased every time you export (regardless of format).
(personally I just use the date, which is why I had not noticed this).
Hmm, i can export different things: single tracks, busses or the master bus. Everything what i currently export represents the current state of the object i do export. In case of exporting the master bus my current export is the current state of my mix, regardless how i name it or if i use the revision appendix at all.
OK! I can do changes to a mix without ever exporting them. But we are talking about exports here, don’t we?
Where do you see the difference between “current mix” and “current export”?
That again depends
Streaming services will process your uploaded file regardless if it meets the criteria or not. That is another round of “normalization”. In this process reducing gain is much less of a problem than adding gain because that can trigger yet another round of peak limiting.
So if your master meets the criteria of lowest dBTP and the most LUFS of the different services you want to upload to, you’re usually good to go.
I think there’s an argument for both scenarios. A new export can be done without changing anything in the mix, and this would result in a new revision even though nothing had been changed.
Or you could do an export tweaking the format settings (such as the normalization settings) which would result in a new revision which is different, although the original mix hadn’t changed.
I note that, if one has different output formats (or settings), these can easily be labelled as both the format can be labelled, as well as the specific export, so one could have:
“My Project_r1_for_mastering.wav” and “My Project_r3_local.wav”
or
“My Project_mastering_r1_Wav (Tagged).wav” and “My Project_local_r3_Wav (Tagged).wav”
You can also use the snapshot name in the filename, so you could have:
“My Project_v1_mastering_r1_Wav (Tagged).wav” and “My Project_v1_local_r3_Wav (Tagged).wav”
My personal view is that if you want version/revision control, you seem to have all of the bases covered, and it’s up to the user to come up with a method of working that does what they need.
I would suggest that, if you want version control of the mix, rather than of the exports, use snapshots, name them appropriately, and use this snapshot name in the export filename. This is also meaningful in that it gives you way to “roll back” to a specific version.
