4 ms·

Loved the video. Didn't love the loud beep near the end, that's at about 3x the volume of the speaker the whole video...

by axaxs 8y ago

CamperBob2 8y ago
YouTube desperately needs an audio compressor feature. Can't imagine why they haven't implemented that yet, it's more or less trivial.
- callalex 8y ago
  I agree that they should, but it’s pretty reductionist and arrogant to call it “trivial”. There is no such thing as a one-size-fits-all dynamic compressor. You would also need a fairly sophisticated content detection system (don’t distort anything that is music, which is a huge use case on YouTube for example). Not to mention adding _any_ steps to their intake pipeline requires more processing power and data moving than you and I will ever touch in our lifetimes.
  - CamperBob2 8y ago
    Speaking as a reasonably-experienced audio and DSP programmer -- and considering that the feature has existed in just about every home theater receiver for the past 20 years -- yes, it's trivial. YouTube has the advantage of being able to preprocess the audio track in its entirety, although most implementations work on a block basis and don't need that. A 'night mode' feature would take about one weekend's worth of work from start to finish. You would also need a fairly sophisticated content detection system (don’t distort anything that is music, which is a huge use case on YouTube for example). No, you need a button that the user can press to turn the feature on and off. It should default to 'off.' For extra points, make it a slider. Not to mention adding _any_ steps to their intake pipeline requires more processing power and data moving than you and I will ever touch in our lifetimes. Compared to the work needed to process the video itself, it would be a total non-issue.
    - dcwca 8y ago
      The audio compression / limiting can be done client-side, at playback time, offloading the cost of the operation
      - Drdrdrq 8y ago
        Even better, the whole limiting could be done client side, in OS or browser.
      - CamperBob2 8y ago
        True, but that would involve modifications to the decode side of the audio codec. That's where the feature should be implemented (if not in the OS itself) but it's apparently not there. It needs to be supported on every platform, and deploying it wouldn't be anyone's idea of trivial. On the server side, they could maintain a separate compressed audio track and switch to it when requested. They should have the ability to do that anyway for alternate languages and commentaries and such. Whether it would be more cost-effective to maintain a separate set of compressed tracks or to decode/compress/re-encode on the fly, I don't know. It might be tempting to maintain caches of compressed tracks created on demand. That way they'd almost never incur a runtime penalty on the server, and also wouldn't have to pay a lot for storage. More than a weekend's worth of work at that point, though.

Loved the video. Didn't love the loud beep near the end, that's at about 3x the volume of the speaker the whole video...

by axaxs 8y ago

Loved the video. Didn't love the loud beep near the end, that's at about 3x the volume of the speaker the whole video...

CamperBob2 8y ago

YouTube desperately needs an audio compressor feature. Can't imagine why they haven't implemented that yet, it's more or less trivial.

callalex 8y ago
I agree that they should, but it’s pretty reductionist and arrogant to call it “trivial”. There is no such thing as a one-size-fits-all dynamic compressor. You would also need a fairly sophisticated content detection system (don’t distort anything that is music, which is a huge use case on YouTube for example). Not to mention adding _any_ steps to their intake pipeline requires more processing power and data moving than you and I will ever touch in our lifetimes.
- CamperBob2 8y ago
  Speaking as a reasonably-experienced audio and DSP programmer -- and considering that the feature has existed in just about every home theater receiver for the past 20 years -- yes, it's trivial. YouTube has the advantage of being able to preprocess the audio track in its entirety, although most implementations work on a block basis and don't need that. A 'night mode' feature would take about one weekend's worth of work from start to finish. You would also need a fairly sophisticated content detection system (don’t distort anything that is music, which is a huge use case on YouTube for example). No, you need a button that the user can press to turn the feature on and off. It should default to 'off.' For extra points, make it a slider. Not to mention adding _any_ steps to their intake pipeline requires more processing power and data moving than you and I will ever touch in our lifetimes. Compared to the work needed to process the video itself, it would be a total non-issue.
  - dcwca 8y ago
    The audio compression / limiting can be done client-side, at playback time, offloading the cost of the operation
    - Drdrdrq 8y ago
      Even better, the whole limiting could be done client side, in OS or browser.
    - CamperBob2 8y ago
      True, but that would involve modifications to the decode side of the audio codec. That's where the feature should be implemented (if not in the OS itself) but it's apparently not there. It needs to be supported on every platform, and deploying it wouldn't be anyone's idea of trivial. On the server side, they could maintain a separate compressed audio track and switch to it when requested. They should have the ability to do that anyway for alternate languages and commentaries and such. Whether it would be more cost-effective to maintain a separate set of compressed tracks or to decode/compress/re-encode on the fly, I don't know. It might be tempting to maintain caches of compressed tracks created on demand. That way they'd almost never incur a runtime penalty on the server, and also wouldn't have to pay a lot for storage. More than a weekend's worth of work at that point, though.