[Arjuna]

”The same thoughtless disregard for basic music fundamentals that plagued the preliminary edits ended up on the final OST.”

As a musician and music-lover, seeing how they brickwalled [1][2] Mick’s tracks in the screenshots only serves to add to the heartbreak of his entire saga.

[1] Loudness War https://en.m.wikipedia.org/wiki/Loudness_war

[2] The Loudness War https://youtu.be/3Gmex_4hreQ

[mrob]

It seems the brickwall mastering was intentionally done by Mick Gordon. See the section starting at "id Software approved my mastering". The alleged "disregard for basic music fundamentals" appears to have introduced more dynamic range, although not in a way that's pleasant to listen to.

[ndepoel]

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.

[mrob]

>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.

[massaman_yams]

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.

[mrob]

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?

[massaman_yams]

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.

[jonorsi]

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.

[Arjuna]

FTA:

”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

[mrob]

This is comparing Doom 2016 with Doom Eternal. It shows strange production in Doom Eternal that is very probably an error (overlapping without crossfade), but it provides no additional information as to why the Doom Eternal OST has low dynamic range.

[Arjuna]

In the tweet, the waveform image on the left is Mick’s original “BFG Division” track from the Doom 2016 OST.

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).

[filoleg]

> It seems the brickwall mastering was intentionally done by Mick Gordon

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.

[mrob]

The edits described in the article have no mention of additional dynamic range compression. The music in the OST is described as "normalized" to 0dBFS, which means simply adjusting the gain. This suggests that the dynamic range was already compressed (which is not unreasonable for game audio, because it will make the sound effects easier to hear).

[filoleg]

The edit described in Gordon's post talks about overlaying tracks with zero crossfading done and instruments clashing, all being done hastily by hand. That alone is a massive contributor to the dynamic range brickwall.

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.

[massaman_yams]

"Brickwall" limiting is about very short-term transient compression; to oversimplify things, those limiters are operating at the timespan of 1-30 milliseconds, more or less.

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.

[filoleg]

> Really doesn't look like it, but I don't have the raw files to measure to know for sure.

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.

[massaman_yams]

Now, applying a mastering limiter to sub-tracks? Extremely novice mistake, and could be described as brickwalling. Certainly within the realm of possibility given the novice quality of the editing here.

[mrob]

Overlapping without crossfading is strange and very likely wrong, but it cannot contribute to brickwalling unless further dynamic range processing is applied, or unless it causes clipping, which is avoided by the described normalization. No further dynamic range processing is described in the article, and no evidence of such processing is visible in the screenshots.

[mort96]

From the article:

> [...] 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.

[mrob]

That's not what "normalising" means. Normalising is just changing the gain of the whole track so the peak level matches your target. And this is obviously what it meant, because if it somehow actually meant dynamic range limiting, we would not see the volume spikes.

[mort96]

Ah, sorry. I read it to mean compression. I see that I'm wrong now. Thanks!