Lowering the volume does not equal introducing more dynamic range. It was just done to avoid clipping when pasting two bits of track on top of each other.
The masters delivered by Mick Gordon were meant for use in the game. I'm not an expert at game audio engineering, but the brickwall mastering may have been intentional to make the music stand out over the rest of the game audio. Either way those masters were approved by id Software for use in the game so nothing was wrong with those.
The problem is that those exact same masters were then used to produce the OST. To do a proper OST, you would have to go back to the source materials, remix them and produce a new master that is suitable for playback as an album. One that isn't as brickwalled and maintains more dynamic range. This is the important part that was skipped by Chad Mossholder and not caught by id Software's internal QA. If you take an already mastered piece of music meant for a different context and just cut it up and splice it back together, without regard for volume leveling, tempo adjustment or proper balancing, then you're inevitably going to produce garbage.
>Lowering the volume does not equal introducing more dynamic range. It was just done to avoid clipping when pasting two bits of track on top of each other.
If you overlap two tracks, and reduce volume to avoiding clipping, the combined track has spikes in volume where they overlap. This is increased dynamic range. But like I said, it is not musically pleasant to listen to, and it's certainly reasonable to complain about it.
You're making an extremely pedantic distinction, which is only correct in a purely technical sense. Which is the worst kind of correct.
Yes, mastering engineers work from track-level dynamic range (usually achieved with slow-response compression) to transient-level dynamic range (fast compression/limiting), and the range in between. When the context for this discussion is about "brickwall limiting", we're talking about very fast, transient-level compression, and your comment mistakes slower dynamic range for the transient-level dynamic range everyone else is discussing.
So, no. In this context, what you're talking about isn't increased dynamic range.
I'm well aware of the difference, as acknowledged by my first post in this thread ("not in a way that's pleasant to listen to"). But it is not pedantry, and it is relevant to the context, because this unusual form of dynamic range provides evidence as to when the dynamic range compression was applied. If it was applied after the edits described in the article, I do not think we would not see the volume spikes.
I do not see a single complaint from Gordon about the dynamic range, only the editing. But there is a paragraph in the article suggesting the dynamic range was intentional:
"Marty says that Chad, apparently working in a hurry, only had my supposed “bricked” in-game score to work with. He points to my so-called “bricked” score and adopts that as the reason behind Chad’s poor editing. But not only is Marty confused and clearly doesn’t understand the mastering process, but he also seems ignorant of how Chad’s editing introduced significant problems."
Note that there is no objective definition of "bricked". I personally tend to prefer higher dynamic range, but I've heard plenty of recordings with higher dynamic range than I would like. It seems very likely that some people prefer lower dynamic range than I do. Arjuna attributed the dynamic range to some unknown "they". There is no evidence for this in the article, or in Arjuna's linked Twitter thread. I believe the most reasonable interpretation is that Gordon deliberately chose low dynamic range as a stylistic choice. If you disagree, how about providing evidence?
Yes, it's clear Gordon has applied a mastering limiter to the tracks he delivered to Bethesda, and given that the style of the music involves heavy processing/effects and multiple levels of compression, a somewhat aggressive mastering limiter seems appropriate here.
But your point about "increased dynamic range" due to the editing errors is a distraction from your claim that Gordon applied a mastering limiter (which he clearly did). It creates ambiguity, because you're using it in a way that's not aligned with common usage in this context. That's part of why you're getting pushback.
In any case, if we want to try to answer the question of why the OST has low dynamic range (in the mastering limiter sense), I am somewhat receptive to ndepoel's argument - it seems reasonable that in-game tracks could be mastered more aggressively, and with lower dynamic range, than what would be appropriate for a proper OST release. Caveat: I haven't done mastering work in the context of game audio so I can't say if that's common practice, but it seems a little more likely than not.
That wouldn't increase the dynamic range, it's just preventing the overlaps from clipping. Both tracks would still have the same dynamic range, the relative overall volume might be different for the track you lowered/increased to match the other one, but I doubt the transition between the two would be considered increasing the dynamic range.
In order to increase the dynamic range of a mastered track you would have to uncompress/master it in the first place. If you are just decreasing/increasing the overall volume, you would have the same dynamic range just at a quieter or louder listening level.
The masters delivered by Mick Gordon were meant for use in the game. I'm not an expert at game audio engineering, but the brickwall mastering may have been intentional to make the music stand out over the rest of the game audio. Either way those masters were approved by id Software for use in the game so nothing was wrong with those.
The problem is that those exact same masters were then used to produce the OST. To do a proper OST, you would have to go back to the source materials, remix them and produce a new master that is suitable for playback as an album. One that isn't as brickwalled and maintains more dynamic range. This is the important part that was skipped by Chad Mossholder and not caught by id Software's internal QA. If you take an already mastered piece of music meant for a different context and just cut it up and splice it back together, without regard for volume leveling, tempo adjustment or proper balancing, then you're inevitably going to produce garbage.