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.
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.
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.
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 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?
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.
”His edits are riddled with these clearly visible mistakes. Anyone comparing my original tracks to his edits can hear (and see, by looking at the waveform [1]) the unmistakable errors introduced during the editing process.”
[1] https://twitter.com/DoominalCross/status/1251690243389927424
In the same tweet, the waveform image on the right is Chad’s edited version of Mick’s track for the Doom Eternal OST, entitled “BFG Division 2020.”
The comparison is valid, because it is Mick’s music, and it also serves to demonstrate the audio engineering expertise on the Doom 2016 OST, which was hailed as a masterwork soundtrack in the genre.
However, Mick did not mix this particular track for the Doom Eternal OST, and this is the critical point of this specific waveform comparison; that is, as Mick expresses in the article (and the waveform comparison demonstrates), the Doom Eternal OST is not entirely representative of his actual work, or the full depth of his audio engineering expertise.
This is due to decisions and modifications that were made without his input (e.g., the aforementioned editing).
Where are you getting this? His in-game music was perfectly fine, and the only instances of brickwall mastering were present within the "official OST" (that was mixed by Chad, splicing together the in-game music poorly). Which Gordon had no hand in whatsoever, outside of providing the source material, i.e., the in-game music.
Gordon explicitly singled out those instances. He didnt say "the track as a whole has a DR brickwall through and through." He mentioned a complete lack of crossfading being the massive contributor to the brickwall and weird tempo changes, and it all checks out.
These edits are a few hundred ms to a few seconds at a time, so it doesn't make sense that Gordon would refer to them as "brickwall".
(Another problem here is that evaluating a mastered waveform's dynamic range by eye is extremely subjective, and I would argue next to useless most of the time. The way these waveforms are shown in the post, we'd be hard-pressed to tell 9db (hyper-compressed) from 14db (pretty good) by eye. Professionals have software and metering to measure this; that's a much better approach.)
Bottom line: do these clumsy edits contribute to brickwalling? Really doesn't look like it, but I don't have the raw files to measure to know for sure. Are the edits good? Not in a million years.
You have access to the official OST of Doom Eternal (which is claimed to have the brickwalling), as well as access to the in-game versions of those tracks (which you can rip out of the game or find the already-ripped ones on youtube easily). I can certainly confirm by playing the game and listening to the ripped files myself that there was no brickwalling in the in-game tracks. However, it becomes very obvious in the official OST.
> [...] Doing so caused dramatic amplitude spikes at the edit point. Chad didn’t bother to crossfade the transition: both files play simultaneously (causing spikes at double the volume).
> To compensate, he “remastered” the edited song by normalising it to 0dBFS — a rudimentary error.
That's why the OST is so incredibly brickwalled.