Adjust bitrate for transcoded audio such as Dolby AC-3

[rechigo 364]

On 9/8/2025 at 8:13 PM, Luke said:

If you look at the transcoding urls, the apps usually request more but then the server caps it. The reason for this is that we've ran into devices that had trouble with ac3 bitrates higher than 384000, and that was just the easiest way to handle it. For this reason, I don't think an option to remove this limit is going to suffice. It might start there, but then you're going to need exceptions for certain devices. So we can't really commit to an option unless we're going to commit to all of that. But we could certainly throw something into the diagnostics plugin to let you disable it.

Could you give us something in the diagnostics plugin please?! This would suffice for me and some other users surely.

[Luke 42077]

8 minutes ago, rechigo said:

Could you give us something in the diagnostics plugin please?! This would suffice for me and some other users surely.

Have you tried the search and replace option? 

[rechigo 364]

53 minutes ago, Luke said:

Have you tried the search and replace option? 

That is something I could do, but won't it be cleared after server restart? I was looking for something more permanent

[Luke 42077]

8 minutes ago, rechigo said:

That is something I could do, but won't it be cleared after server restart? I was looking for something more permanent

Right you had asked about the diagnostics plugin so I was responding to that.

[rechigo 364]

3 minutes ago, Luke said:

Right you had asked about the diagnostics plugin so I was responding to that.

Well you mentioned a few posts before that you guys could put something (toggle) into the diagnostics plugin to disable the bitrate cap. Would that option persist server restarts if it was added?

[Luke 42077]

12 minutes ago, rechigo said:

Well you mentioned a few posts before that you guys could put something (toggle) into the diagnostics plugin to disable the bitrate cap. Would that option persist server restarts if it was added?

To be honest I wasn't thinking about that. Typically that plugin does not persist it's options.

[rechigo 364]

1 hour ago, Luke said:

To be honest I wasn't thinking about that. Typically that plugin does not persist it's options.

What clients have the issue of not being able to handle higher dolby digital bitrates? Why not instead of capping the bitrate because of those clients, just transcode to AAC at a higher bitrate for compatibility sake? Or do those clients have issues with AAC at higher bitrates as well

[Luke 42077]

3 hours ago, rechigo said:

What clients have the issue of not being able to handle higher dolby digital bitrates? Why not instead of capping the bitrate because of those clients, just transcode to AAC at a higher bitrate for compatibility sake? Or do those clients have issues with AAC at higher bitrates as well

I definitely remember Roku but there will undoubtedly be others.

[ebr 16169]

14 hours ago, rechigo said:

What clients have the issue of not being able to handle higher dolby digital bitrates?

Fire devices are problematic and, I imagine, a number of TVs.

14 hours ago, rechigo said:

Why not instead of capping the bitrate because of those clients, just transcode to AAC

Because almost no systems support multi-channel AAC.  DD gets us 5.1.

[rechigo 364]

14 hours ago, Luke said:

I definitely remember Roku but there will undoubtedly be others.

So what I'm thinking of doing is taking this https://github.com/makinori/emby-custom-ac3-bitrate which was created by a user in this thread and modifying it to support cases where Emby transcodes to AAC or MP3 at lower bitrates as well. Basically a more advanced search and replace that will be able to "Man in the Middle" between Emby and FFmpeg to rewrite ffmpeg command arguments, so no worries about persisting server restarts. 

Now I have a question... Does stats for nerds on all clients actually probe the file being played, or is it just displaying the bitrates the server reports back? Just to make sure whether or not stats for nerds is a reliable indicator to show if my above solution is even working at all, or if I'll have to go sniffing through transcode log files.

[Luke 42077]

2 hours ago, rechigo said:

So what I'm thinking of doing is taking this https://github.com/makinori/emby-custom-ac3-bitrate which was created by a user in this thread and modifying it to support cases where Emby transcodes to AAC or MP3 at lower bitrates as well. Basically a more advanced search and replace that will be able to "Man in the Middle" between Emby and FFmpeg to rewrite ffmpeg command arguments, so no worries about persisting server restarts. 

Now I have a question... Does stats for nerds on all clients actually probe the file being played, or is it just displaying the bitrates the server reports back? Just to make sure whether or not stats for nerds is a reliable indicator to show if my above solution is even working at all, or if I'll have to go sniffing through transcode log files.

It's a combination. Some things will pull from the ffmpeg log dynamically. I'm guessing the audio bitrate will not be done like that though.

[Reaper47 11]

It's strange thas there are devices which claim DD support but have issues with 640kbps. AFAIK most streaming services use either DD+ or DD at 640kbps, so if those devices are outputting surround sound from Nretflix etc, itwould seem like they shouldn't have problem with its playback from emby. Or at very least 448kbps should be universally compatible since this is what most DVD's had. 640kbps mostly started to appear with Blu-Ray, but I might be wrong

[visproduction 315]

Ku,  You are conflating bitrate with Khz an audio measurment.
https://www.reddit.com/r/audio/comments/raanvi/bitrate_vs_khz/

Quote

Sample rate, measured in Hz, is a number of samples per second. It determines the bandwidth of the audio, which is half of the sampling rate. The bandwidth audible to humans is 20 Hz - 20'000 Hz, so the sampling rate of 40'000 Hz, plus some margin for technical reasons, is all that's needed for playback. Hence 44'100 Hz (or 44.1 kHz) used in CD-Audio.

Bitdepth, measured in bits, is how precisely are those samples' values stored. When the analog audio is sampled, the sample value is rounded to the nearest level that can be represented digitally. The outcome of this rounding error is a background noise, similar to white noise. It limits what is the quietest signal that can be captured and so it determines the dynamic range of audio. With 16 bit the noise is 96 dB lower than the full signal, so in normal circumstances it is already not audible.

Bitrate, measured in bits per second, is amount of data needed to store 1 second of audio. In general you take the size of the audio file in bits (1 byte = 8 bits), divide it by the length of the audio in seconds and you get bitrate.

With uncompressed audio file, like WAV, it can also be calculated from sampling rate, bitdepth and the number of channels. For example, for WAV file with 2 channels of 16 bit audio with 44.1 kHz sampling rate, the bitrate is 2 * 16 * 44'100 = 1'411'200 bits per second, or 1'411 kbps.

With losslessly compressed audio file, like FLAC, it depends on how well the encoder could do its job.

With lossy compressed audio file, like MP3, you usually pick the desired bitrate during encoding, for example 320 kbps, and the encoder tries to remove enough data to reach the bitrate while compromising the audio quality as little as possible.

 

[Reaper47 11]

No, I meant kbps, as in "kilobits per second" (kb/s)