Hacker News Reader

Comment by massaman_yams | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com