@samhutchins I love this idea! More power to the art of noodling! :)

And I had never thought about it that way before but, you're right, the --audio-width option does overload the decision about track layout with a decision about audio format. I suppose I originally did that to simplify things for the user, but it doesn't necessarily make sense now.

The --audio-format option is a great way to override passthrough if you always want AAC or AC-3. Nice. Should we add all to the argument list to cover both stereo and surround layouts, i.e.: --audio-format stereo|surround|all=ARG ?

This definitely makes --prefer-ac3 unnecessary.

Also, what do you think about just deprecating--audio-width and let it behave the way it does now for backward compatibility and just implement your new behavior as a --audio-layout option? That might make it more clear as to what it does.

You've also snuck in our favorite behavior as the default, width=stereo. Clever. :)

Do you want to start a patch with this or do you want me to try a stab at it?

@samhutchins BTW, this is much smarter than how I was thinking about solving this problem. Thanks!

@donmelton

Adding all to --audio-format is a good shout, nice.

I'd be fine with --audio-layout TRACK=stereo|surround|double, but I think having both --audio-width and --audio-layout might be a bit of a mess to implement.

Here's the thing about the default audio width: I'm mostly fine with the default the way it is. The one caveat I have is that having the stereo track be dpl2 seems pointless if you have a 5.1 track with the same audio. Given that, I think the default should either be: width=double and mixdown=stereo, or width=stereo and mixdown=dpl2. The impression I get from you is that you'd rather have one output track by default, which I can get totally get behind, and if you're gonna only have 1 track by default I think it may as well be dpl2 stereo. I actually use width=double and mixdown=stereo as my default though.

I haven't given a great deal of thought to the implementation to be honest. If I get time this Sunday I'll have a look. I think that whether I submit a pull request for this or not, you'll be writing a lot of the code ;-). I'm still not overly familiar with Ruby, so I'm sure I'll miss some Ruby idioms as I implement it. I'll try and have a crack on Sunday though, and I'll let you know how I get on

@donmelton Although if you get to implementing this before I do, you'll hear no complaints from me. Don't wait on me if you get the itch.

@samhutchins Yeah, leaving the existing --audio-width implementation in place while implementing a new --audio-layout option would be tricky. But I would rather attempt it for the same of backward compatibility. But if it's too much of a mess, we can throw up our hands and just break shit.

Oh, I agree that if you have a 5.1 AC-3 track then a Pro Logic II AAC track is pointless for MKV output, but it might still be desirable for MP4 output since the AAC track comes first. I think we should ask more users about that. But I can easily be convinced that you're right.

The main reason I would prefer a single audio track is saving space. In a way, I don't care whether that's a single AAC or AC-3 track. Obviously you get a lot more savings with AAC for a small loss in fidelity. I'm also thinking ahead to when the compatibility problems are solved with multitrack AAC. That's already happened on Android. Now Apple and Roku need to get their shit together on it. :)

As to the implementation, we'll figure it out. I may take a look myself later tonight. I'll let you know, sir.

Lol, that container-dependent track ordering is possibly another thing to reconsider... I'd forgotten about that

Something occurred to me today, what if someone wants to pass through audio when possible, but specify the fallback encoder?

I've assumed that, for surround input, if it can't be passed it should be AC3. I wonder if we should think about allowing users to specify a fallback encoder, as well as forcing a particular format. Not sure how that would look though

@samhutchins Agreed, specifying the fallback encoder would be useful if, for example, other discrete surround tracks were in E-AC-3 format instead of AC-3. Maybe we can just infer it from any choice with the --ac3-encoder option? Or do you think we need to make AAC a fallback choice as well?

I'm struggling with this because I'm not sure how to express it, so let me just ask in plain English.

What if the audio options were abstracted? So, for my use case, it would always look like this:

--audio-track-to-convert=1 --audio0-order=HD,AC3 --audio0-fallback=AAC
--audio-track-to-convert=1 --audio1-order=AC3,AAC --audio1-fallback=AAC

So essentially, that would tell it "Hey, I want two audio tracks. Check audio 1 and passthrough if it is anything in this list. Failing that, give me my first track as AAC it is! Second track should be track 1 also, passthrough if it meets criteria, otherwise, make it AAC."

@samhutchins AlthoughHandBrakeCLI allows you to specify the fallback encoder on a track-by-track basis with their error-prone comma-separated lists, I'm not sure if we need that kind of granularity. But since there are so many audio options in HandBrakeCLI, maybe we need a generic and flexible audio option to specify all of these that took an argument like --audio-width does now, i.e. TRACK|main|other|all?

@khaosx Your comment arrived just before I posted mine to @samhutchins! :)

Yeah, I'm not crazy about your syntax (especially adding the index to the option name itself), but that's the idea I was going for.

@khaosx But, to be clear, I meant a single option and argument list specifying a single or set of tracks and multiple attributes for that specification. Lemme noodle on it a bit and I bet I can come up with something.

I'll probably dread writing the parser for that argument list though. :)

@khaosx @samhutchins And if we implement this generic option for audio, we should also consider doing something similar for subtitles. I do like this idea but it's like pulling on a string after awhile. :)

Hi Don (& Sam),

As always, thanks for maintaining and improving these amazing tools! :-)

Quick question: if you rip a BluRay with 5.1/7.1 FLAC audio, why would the default behaviour want to return a stereo option?

Perhaps I've misunderstood the intention of the new defaults but isn't the two-track 5.1/2.0 default more in-line with the normal expectations? One file with both 5.1 + 2.0 making it multi-device compliant?

Just making stereo the default seems like a regression especially for new users or those who don't tweak defaults. I understand why a stereo default might be popular (for mobile and many home set-ups) but would it not be better to have 5.1/2.0 remain default with something simple like '--stereo' to set transcode-video to complete what's proposed above? I'm thinking of something along the lines of the --mp4 switch idea. Just a thought ...

@rhapsodians Good question, Joe! A two-channel stereo track can still contain surround sound information. That's exactly what Dolby Pro Logic II format is. While such surround channels might not be discrete, matrix encoding allows them to be reconstructed with amazing fidelity.

Now, when you use --audio-width main=stereo and your input track is multi-channel, that's exactly what happens. You get a two-channel matrix-encoded Dolby Pro Logic II 128 Kbps AAC format stereo track in the output.

This is exactly how I transcode all of my audio. Why? Simply put, it still sounds great on my 5.1 home theater system and my stereo headphones at the same time. More importantly, It makes the output a shitload smaller than transcoding an extra 640 Kbps AC-3 track. :)

But, like you, I am also cautious about changing the default configuration. Either to make audio output a single track or even to change the AAC track to a stereo-only mix.

As I always say, let's not be hasty. :)

But if we do make a change, we'll make it easy to go back to the current behavior.

I wasn't aware about reconstructing the Pro Logic II formats ... I must read up on this :-) Research time over the weekend!

I think whatever is decided, then flexibility to cover all the bases is key whether it's a two-channel 128kbit AAC stereo or 640kbps AC-3+128 stereo. Many people like customisation which is provided in bucket-loads via the options.

You can still make the change and for most people, so long as the impact/functionality is understood then it will just work out ok. But maybe it's time to rethink some of the help sections.

I'm guessing most people will be transcoding BluRay and DVD for the most part with 4k/UHD being the next area (for those with iMac Pros or lots of patience listening to whirring fans!). So why not have a new table of examples covering some basics?

For example (better viewed in a table):
1 Audio Track (default)
Original Source: BluRay
Extracted Video: MKV (AVC) 25MB/s
Extracted Audio 1: 8-channel FLAC 7.1 2.1Mb/s
Target Video: MKV
Target Audio: Track 1: 160kb/s 2-channel 2.0, AAC Stereo
Command: transcode-video --crop <values> --output movie.mkv <Matroska file>

2 Audio tracks (5.1 AC-3 plus 2.0 AAC stereo)
Original Source: BluRay
Extracted Video: MKV (AVC) 25MB/s
Extracted Audio 1: 8-channel FLAC 7.1 2.1Mb/s
Target Video: MP4
Target Audio: Track 1: 640kb/s 6-channel 5.1, AC-3 (Dolby Digital); Track 2: 160kb/s 2-channel 2.0, AAC Stereo
Command: transcode-video --mp4 --crop <values> ---audio-layout TRACK=double <Matroska file>

3 Audio tracks (5.1 AC-3 plus 2.0 AAC stereo plus Director's Summary)
Original Source: BluRay
Extracted Video: MKV (AVC) 25MB/s
Extracted Audio 1: 8-channel FLAC 7.1 2.1Mb/s
Extracted Audio 2: 6-channel AC-3 Dolby Digital 448kb/s
Target Video: MP4
Target Audio: Track 1: 640kb/s 6-channel 5.1, AC-3 (Dolby Digital); Track 2: 160kb/s 2-channel 2.0, AAC Stereo; Track 3: 160kb/s 2-channel 2.0, AAC Stereo (Director's Summary)
Command: transcode-video --mp4 --crop <values> ---audio-layout TRACK=double --main-audio 1 --add-audio 2=DirSummary <Matroska file>

If something like this were available in tabular format, I suspect people would not only understand the audio defaults more easily but also experiment more. In theory you could also do something similar with video options (from --avbr to --target big --quick etc.)

Best wishes,
Joe

@damorrison Another good question, David! I should add this to the FAQ:

I definitely do not want to ever do this. :) Forgive my cheekiness, sir, but I feel it is one of the great weaknesses of HandBrake having all those presets and one of the great strengths of transcode-video having none. Seriously.

To this day, one of my big frustrations when helping folks who use the HandBrake app, because they can't quite handle the command line, is explaining all those mother forking presets to them and helping them choose which one to use. Because it's not as obvious as you would think.

The fact that you still need to choose different presets for Blu-ray rips as opposed to DVD rips just boggles my mind. This is a problem I solved with the very first version of transcode-video.

And there's no reason that you can't configure MKV or MP4 output to work correctly and beautifully on Apple, Android, Roku, etc. devices at the same time. That's what transcode-video does now and I don't want to change that.

Sorry, that answer was a little longer and harsher than I intended. :)

Please keep questions like this coming!

@rhapsodians Hmmmm, adding something like this, in tabular format as you say, to the README is a damn good idea.

And this is really making me think that we should expand the project to have a Wiki so we can really elaborate on stuff like this.

Plus, we can effectively (sort of) do presets, as @damorrison suggests, by documenting recipes in a Wiki. I don't want to build them into the tool, but the concept is still useful for tuning and understanding the options.

BTW, let me just add here how much I enjoy all the contributors and commenters who participate on this project. I am so honored to have you all even pay attention to what goes on here. Thank you all, so much!

I think the idea of Wiki recipes (i.e. worked examples) is a great one. Everyone will have their own 'presets' or like to make their own. But simple recipes for common scenarios like default, 5.1 AC-3 only, 5.1 AC-3 + Stereo, 5.1 AC-3 + Stereo + Director's Commentary (with notes) would be great.

I know I've set up my own aliases in .profile to deal with all these and even have a preset (--preset veryfast --chapters 3 --main-audio 1 --add-audio 2=DirSummary) to ensure I pick/test the correct audio track for the Director's summary before proper transcoding starts.

Might be worth a trial as I think many of us would be happy to contribute to ease the workload and to trim it down to cover the most useful recipes/preset examples.

@rhapsodians Agreed. And those would be useful contributions. I can even add a "how to" on my own hack that automatically adds commentary tracks (spoiler: I look for audio tracks in the rip with "Commentary" in the title :).

The key thing is getting the structure right for a Wiki. Obviously you want it to grow organically but you need to start with some sort of organization. Maybe just offloading sections of my massive README is a good way to think about it.

I'll noodle on this during the next few days and when I get back from the Sierras (I'm presently at my cabin), maybe I can launch it in the next week or so.

Nice one Don ... and I'm off to bed as it's getting late here in the UK. Just hoping I drop off to sleep and not start thinking about Wiki examples before the baby wakes up! Enjoy the Sierras! :-)

@damorrison Indeed! I think a Wiki would be a good repository for such scripts and explainers for how they work. The goal would not only be utility but education.

@samhutchins OK, I got the itch. :) At least to write the --help text. Which is always a good start for me. If I can describe it to the user then I can probably implement it:

    --audio-format surround|stereo|all=ac3|eac3|aac
                    set audio format for specific width or all widths
                      (default for surround: selection from `--ac3-encoder`)
                      (default for stereo: aac)

...and this small modification to an existing option (the fallback part of the description):

    --copy-audio TRACK|all
                    try to copy track selected by number in its original format
                      falling back to `--audio-format` behavior if not allowed
                      or try to copy all tracks in same manner
                      (only applies to main and explicitly added audio tracks)
                      (can be used multiple times)

To summarize what this means:

• We only add one new option, --audio-format, as per your original proposal.
• We don't change the name or, to a certain extent, the behavior of --audio-width. We just narrow the scope of what it does.
• We don't add a new fallback option. We just infer what the user wants based on their usage of --audio-format and/or --ac3-encoder whenever they explicitly try to copy tracks.
• We don't change any default behavior at this time. (Other than falling back to AAC format for stereo tracks when a copy is not allowed.) Although I definitely want to consider changing defaults later!

What do you think?

Also, as much as I like the idea by @khaosx for generic and flexible per-track audio options, I can't come up with a succinct syntax for that yet. Not that I won't stop trying! I think one way to do this might some sort of specialized version of --handbrake-option since it's really an advanced usage.

@samhutchins D'oh! I forgot to list in that summary:

• We deprecate --prefer-ac3. It will still work but not be documented. We just implement it as a special case of --audio-format.

@donmelton No, this is a better implementation than my idea. Mine was too complex, and likely would result in a huge mess. Ironically, I've got no dog in this hunt. If I'm reading this right, my current "--copy-audio 1 --audio-width all=double" won't need to change. I still want to passthrough lossless audio, with a non-theater-receiver secondary track.

@samhutchins Yeah, it does sound funny and not in the amusing way. But basically that would only keep AC-3 stereo format tracks in surround widths and not affect stereo widths. Maybe I should have included double as a choice in there too? Not sure if that would have helped.

Obviously the nomenclature I suggested sucks mightily so I'm open to ideas for how to explain that better. :)

BTW, this scoping behavior I'm suggesting is not hard at all to implement. Just really damn hard to describe.

@donmelton Well, it seems that the scoping thing is a bitrate thing? Could the argument be a maximum bitrate to pass?

@samhutchins That could work but in my example scenario I really only want the behavior in the main track, no matter what the input bitrate is.

@samhutchins OK, I've decided that it's not worth worrying about modifying the --keep-ac3-stereo option now and there's probably a way to solve the scenario I described yesterday without such a radical change in the future. Besides, I can't think of a decent syntax for it now. :) So let's table that.

But, before I pull the trigger on this very audio-focused release, do we want to also consider changing the default mixdown for stereo tracks from dpl2 to stereo now, as @dkoenig01 suggested? Because I'm a lot more open to that than I've sounded in comments here. :)

In fact, I think it's inevitable that we phase out DPL2 with the adoption of smaller and better (at least smaller and better than AC-3) discrete surround formats like E-AC-3 and multichannel AAC.

Hell, I'm even open to making the default surround format E-AC-3 eventually. :) Obviously I still love DPL2 for its size and portability, but 384 Kbps E-AC-3 is only twice the size, sounds much better and portability keeps improving every day.

So, do we pull the bandaid off and switch the mixdown default now? I mean, Sam, the way you designed the code it's a freakin' one-line change so it's pretty easy. :)

@samhutchins @dkoenig01 Or, do we wait on changing the mixdown default before we get more feedback? Again, I think it is inevitable but maybe we shouldn't be hasty until a lot more of us get a say about it.

@donmelton Depends on what you want the default audio width to be. If it's double, I'd change the stereo mixdown to stereo, otherwise I'd leave it as dpl2 personally. If someone does --audio-width main=stereo for a bunch of rips, then get's a surround capable system later they can still have surround audio without re-doing the rip. It's not as good, but it's better than nothing. Plus I've not come across any situations in the wild where the stereo image sounds wrong.

On the other hand, I guess the more conservative thing to do is make the default mixdown for stereo stereo, which is I guess more honest and isn't ever going to have the panning problem DPL2 has.

@samhutchins So, you are of two minds about it as well. :)

Yes, setting the stereo track in a double width to a true stereo mixdown instead of dpl2 seems safe since you also have the same audio there in a true discrete multichannel format. But I think it's complicated explaining to the user that other stereo conversions in surround and stereo widths default to a dpl2 mixdown. Even though that is sensible to you and I. :)

Then there's the problem of changing the mixdown if we defaulted it to some hybrid configuration like that. Do we introduce a new split or mixed argument for the --mixdown option to describe that default?

So it's complicated. :)

Then there's the other problem that now, after prodding by @dkoenig01, I'm beginning to hear some of the imaging and panning problems that folks have been complaining about with DPL2 as I rigorously review my own transcodings. And, sadly, these are noticeable when listening with surround or stereo systems.

Certainly these issues and artifacts don't happen all the time but it's now impossible to un-hear them. I blame @dkoenig01 for this. :)

Anyway, I agree that the conservative and safe thing to do is change the default mixdown to stereo. The question is, do we do it right now?

@samhutchins OK, I decided not to change the --mixdown default now. :)

Just gem update to get version 0.24.0.

Thanks again for the new features, Sam!

And thanks to @khaosx, @rhapsodians, @damorrison, @vr8hub, @dkoenig01, @klogg416 and everyone else I forgot to mention for all your feedback on this one! Y'all rock!

I'm closing this issue since the feature has been released but feel free to keep commenting here until we open some new audio issues to cover all the other cans of worms we opened. :)

Well, having just said that I'd not come across anything that sounded funny with dpl2 in the wild, I've just come across something that sounds funny. Opening sequence to Baby Driver is really far right in my dpl2 stereo track when using headphones

@samhutchins Ouch! Sorry if ruined DPL2 for you.

I don't have "Baby Driver (2017)" but I've noticed that shift of rear channel audio (I think) to the right when listening with stereo headphones on too damn many other titles now. It's really obvious (and annoying AF!) on "Annihilation (2018)" at the beginning.

Worse is when audio effects sometimes shift back and forth in rapid succession between right and left. Because I can notice that listening both on stereo headphones and with my 5.1 surround system.

Again, you can't un-hear any of this.

So I'm in the process of re-transcoding all of my titles again. You could do the same and give yourself an even better excuse for switching to --avbr. :)

Seriously, I think we really do need to switch the default for --mixdown now. I'll open an issue soon proposing that, probably today.

I'll also open separate issues proposing an expanded syntax for --mixdown and another proposing we change the the default encoder and bitrate for surround tracks to eac3, i.e. Dolby Digital Plus or E-AC-3, at 384 Kbps.

I really am re-transcoding all my main title audio to E-AC-3 at 384 Kbps because:

• It solves the DPL2 problems we're hearing.
• Using Plex on the Roku attached to my big 5.1 surround system passes it through unchanged.
• Plex dynamically mixing it down and transcoding it to stereo on my other systems still sounds great.
• Plex dynamically transcoding it to 5.1 AC-3 still sounds really damn good (essentially transparent) because it's doing that at 640 Kbps.
• Roku and Apple both consider that even E-AC-3 at 192 Kbps sufficient for multichannel 5.1 audio so 384 Kbps is probably overkill and just good insurance.
• 384 Kbps is still only a little over twice the size of two-channel AAC so it takes just 5-6% the size of your output instead of 10% or more like 640 Kbps.
• Roku and Apple both consider E-AC-3 just as good as AC-3 at half the bitrate and after a lot of testing this weekend, I would have to agree.
• E-AC-3 is getting hardware adoption a LOT faster than multichannel AAC.

So, if you do decide to redo your library (again) then I would recommend it.

I distinctly remember someone recently telling me "take the defaults, they're all you need". If only I could remember who that was…

1. What does the above command-line look like? (I see both --ac3-bitrate and --pass-ac3-bitrate options, but can find no info on the difference, so I'm not sure which would be used.)
2. How is Plex "doing that at 640Kbps" if only 384Kbps is available in the source? (I searched around for info on Plex's transcoding and didn't find something that looked like the answer to this.)
3. If (2nd bullet) Plex passes the multi-channel unchanged, why (4th bullet) would Plex need to transcode it to a different multi-channel format? Oh, wait, is that because system Nil as default for path argument #1 can handle EAC3 and system Scripts fail to start on Cygwin #2 can only handle AC3? Yes, probably so. Never mind, move along, nothing to see here…

@damorrison Great feedback and thanks!

While I'll open a proposal about moving to E-AC-3 as the default for surround, I doubt we actually do that right away. I just want to get feedback, like yours, on this early so we can weigh the risks.

We’ve discussed how dlp2 sounds on a 5.1, but are there views on if you only have 5.1 and listen to it in just stero? Use case is listening to a movie with a Dolby digital 5.1 on an iPad.

Good question! If you use a versatile player like Infuse.app or VLC.app which can decode many multichannel audio formats, you'll just get a nice, smart stereo mixdown of that audio without transcoding it. If you use TV.app, or whatever the native Apple-supplied player is, then you'll get the same behavior, like the other players, but limited to AC-3 and E-AC-3 formats.

But keep in mind that if you use wireless earphones, such as AirPods like I do, then it's possible that audio, any audio really, might be transcoded behind your back (or, technically, your ear. :) ).

@vr8hub ...

I distinctly remember someone recently telling me "take the defaults, they're all you need". If only I could remember who that was…

Well played, sir. Well played. :)

OK, on to your great questions:

1. The command line I'm using includes --ac3-encoder eac3 --ac3-bitrate 384 in it. I don't include --pass-ac3-bitrate because I want to continue allowing audio up to 640 Kbps AC-3 and E-AC-3 to be copied unchanged without transcoding.

2. When Plex has to transcode any non-AC-3 5.1 audio, it seems to always use 640 Kbps (or thereabouts) for that even if the original is at a lower bitrate. That's because 640 Kbps is about as transparent as AC-3 is ever going to get.

3. Yes. Plex knows what the target system can handle so it only transcodes when necessary. And the Roku does a good job (most of the time) of telling Plex what the system it's connected to is capable of.

Anything else?

@donmelton

Well, I think I am going to re-do the library. Which sucks, because I don't have the hard drive space anywhere to keep the originals (well, I could fill the NAS but I'd rather not). Plus a lot of my library came from DVDs at my parents house, and re-ripping all those would suck...

In any case, I can't trust my AAC track any more, so a do-over is inevitable.

See you on the other side

@donmelton

1. And here I thought I couldn't possibly be more confused. I thought the option was setting the output rate. Are you saying the --ac3-bitrate 384 option ignores bitrates above 384 and just passes them through? What if the source is FLAC? Isn't the option telling it to encode that FLAC input as EAC3 output? (I know, I know, I should wait for the Wiki.)
2. Well, right, but encoding at 640Kbps is wasted if the input is 384. IOW, if the input is 384, it doesn't really matter what Plex is doing as long as it's doing it at 384+. (And how do you know what Plex is doing? Does it show that info in its log somwhere?)

I just read one of Plex's support documents on audio. They spent a lot of time saying, "Don't use passthrough". Which, even after reading it, doesn't make much sense to me. I don't want Plex determining what my audio is, I want to determine what my audio is. I'm going to a lot of trouble to get the audio right in the file. Why on earth wouldn't I want Plex to leave it alone? (Rhetorical question; this is not a Plex forum. Just an example of why poking myself in the eye with a stick might be less painful than trying to figure out all of this transcoding audio stuff.)

@donmelton

One more thing!

My set-up at home can't handle E-AC3 or (AFAIK) 5.1 AAC, so it's 640kbps AC3 for me for the forseeable future

@samhutchins ...

See you on the other side

The other side of madness, right? :)

My set-up at home can't handle E-AC3 or (AFAIK) 5.1 AAC, so it's 640kbps AC3 for me for the forseeable future

Yeah, a lot of users have similar setups so I doubt very seriously that we'll change the surround default soon. I just want to start getting feedback now.

@vr8hub ...

1. Go back and re-read what I wrote there. I think you're confusing --ac3-bitrate and pass-ac3-bitrate in that paragraph. To be clear, the --ac3-bitrate option sets the audio output bitrate. But it's the --pass-ac3-bitrate that sets the passthrough bitrate. And you'll probably never want to change the passthrough bitrate.

2. No, it's not wasted. If the input format has more efficient compression that the AC-3 format, and E-AC-3 is about twice as efficient as AC-3, then it makes sense to use 640 Kbps, the maximum bitrate for AC-3, when re-transcoding. And keep in mind that almost every audio format out there is more efficient than AC-3. It's even older and skankier than MP3.

I just read one of Plex's support documents on audio. They spent a lot of time saying, "Don't use passthrough". Which, even after reading it, doesn't make much sense to me. I don't want Plex determining what my audio is, I want to determine what my audio is. I'm going to a lot of trouble to get the audio right in the file. Why on earth wouldn't I want Plex to leave it alone? (Rhetorical question; this is not a Plex forum. Just an example of why poking myself in the eye with a stick might be less painful than trying to figure out all of this transcoding audio stuff.)

Which document? Because I'm pretty sure that's not the correct interpretation. :)

Plex usually refers to the equivalent of "passthrough" with terms like "direct play" and such. And they've always been helpful about how to avoid dynamic transcoding.

@donmelton I'm certainly confused, but I'm confused because I read what you wrote, not because I didn't read it. :) I know the options are different. My (perhaps mis-stated) question was to clarify how they interract with each other and with the input. Let me ask differently — what is the difference between the two? How are the two choosing what they're processing? To what kind of input do the two options apply? (Hence my "what if input is FLAC" question.)

I either convert the input audio to an output format, or I passthrough the input audio to an output format. I don't understand how (or why) I do both, which is what your statement sounded like what was happening. (But I'm confused, so that might not be what was meant at all.)

@vr8hub Oh! My bad. I misunderstood your question. Sorry about that.

The --ac3-bitrate option simply controls the output bitrate when transcoding surround sound audio, e.g. multichannel FLAC tracks in your input would be, by default, transcoded to AC-3 format at 640 Kbps. But you could add --ac3-encoder eac3 --ac3-bitrate 384 to your command line to transcode them to E-AC-3 format at 384 Kbps.

The --pass-ac3-bitrate option only considers AC-3 input (or AC-3 and E-AC-3 input if you used --ac3-encoder eac3). It ignores, for example, FLAC and all other audio formats when considering what is copied.

I either convert the input audio to an output format, or I passthrough the input audio to an output format. I don't understand how (or why) I do both, which is what your statement sounded like what was happening. (But I'm confused, so that might not be what was meant at all.)

Yes, and normally you don't need to screw around with the rules for when passthrough happens. Just trust transcode-video to do the right thing. Which hopefully it has been doing for you.

That recommendation for @samhutchins to try was about modifying the default conversion behavior (i.e. using those --ac3-encoder eac3 --ac3-bitrate 384 options and arguments).

Did that clear things up any?

@vr8hub BTW, here's the Plex support article describing the difference between "Direct Play," "Direct Stream" and "Transcode" and what those terms mean in their world:

https://support.plex.tv/articles/200430303-overview/

@donmelton So, --ac3-bitrate handles what isn't [e]ac3 in input, and pass-ac3-bitrate handles what is [e]ac3 in input. Got it, I think. So FLAC input is handled by --ac3-bitrate, while [e]ac3 input is handled by --pass-ac3-bitrate. Hmmm. But --aac-encoder is a different option that presumably handles AAC input. So does --ac3-bitrate just handle FLAC input?

And from your statement above, the # on --pass-ac3-bitrate says "pass through anything at this rate or below." What happens to an [e]ac3 input above that rate? Is it converted to the --pass-ac3-bitrate or the --ac3-bitrate rate?

(Forgot to mention, the Plex article was this one.)

@vr8hub Sorry, it was dog and dinner time there for awhile. You know how it is. Anyway...

So, --ac3-bitrate handles what isn't [e]ac3 in input, and pass-ac3-bitrate handles what is [e]ac3 in input.

Yes, you've got it! And that's actually a simpler way to put it than I did. Thanks! I will steal that verbatim, sir, for another support answer. :) Seriously, you're on a roll.

But --aac-encoder is a different option that presumably handles AAC input. So does --ac3-bitrate just handle FLAC input?

Great question! And the answer is... uh... not exactly. :)

The default format for surround output is AC-3 so the --ac3-encoder option configures whether you get AC-3 or E-AC-3.

The default format for stereo output is AAC so the --aac-encoder option configures... which encoder to use in order to get that AAC output. It doesn't change the format, just the encoder.

And this silly option is necessary because on Windows and Linux, sometime folks don't want the FFmpeg AAC encoder. On macOS, it's a really bad idea to ever change the AAC encoder because the default, ca_aac (the prefix is for "Core Audio"), is probably the best AAC encoder in the world.

Anyway, that's not the only complication.

Remember the new --audio-format option? Well you can use that to make stereo output use AC-3 or E-AC-3 format. So, if you add --audio-format stereo=ac3 to your command line, then the --ac3-encoder option affects that too.

And from your statement above, the # on --pass-ac3-bitrate says "pass through anything at this rate or below." What happens to an [e]ac3 input above that rate? Is it converted to the --pass-ac3-bitrate or the --ac3-bitrate rate?

Unless you add --ac3-encoder eac3 to your command line, E-AC-3 input is treated just like FLAC, DTS, PCM, etc. Meaning that it will be transcoded.

But let's say you do add --ac3-encoder eac3 to your command line. Since the default passthrough bitrate is 640 Kbps, any E-AC-3 audio above that bitrate will also be transcoded. You would have to add --pass-ac3-bitrate 1536 to your command line to allow any E-AC-3 audio input to qualify for passthrough and be copied instead of transcoded.

Confusing? You bet your ass it is. :) But imagine what it's like to code this stuff.

(Forgot to mention, the Plex article was this one.)

Ah. OK, no wonder you got confused. :) That's the guide for the player, not the server.

@donmelton

Unless you add --ac3-encoder eac3 to your command line, E-AC-3 input is treated just like FLAC, DTS, PCM, etc. Meaning that it will be transcoded.

Right, I understood that (some things are so simple even I can get them). Without that option, eac3 would be transcoded to ac3. And with that option, ac3 is transcoded to eac3. (And the --aac-encoder was a dumb question, even for me; I was not paying attention.)

You would have to add --pass-ac3-bitrate 1536 to your command line to allow any E-AC-3 audio input to qualify for passthrough and be copied instead of transcoded.

Right, I also understood that (I know, twice in one day, it's kind of shocking to me, too). My question was that if the bitrate was higher than whatever was specified (or defaulted) on the --pass-ac3-bitrate option, what bitrate is it transcoded to? Does it use the --pass-ac3-bitrate ("convert anything above this pass-through rate to this rate"), or does it use the --ac3-bitrate ("convert anything above this pass-through rate to the --ac3-bitrate"). IOW, with --ac3-bitrate 384 --pass-ac3-bitrate 640, and a bitrate of 1536, is the 1536 transcoded to 384 or 640?

And a hearty thank you for your patience. I actually (somewhat) understand all of the various audios out here in the real world. (IOW, I know the difference between TrueHD and DTS and AC3, etc. as it comes to a receivers, Blu-ray, etc.) What I have no grasp at all of is how all of this is handled and transcoded and used and abused in the transcode world. In my Handbrake GUI days, I avoided the audio tab; it had something about AC-3 and something about passthrough, but I didn't understand it and left it alone. I maybe should leave it alone now, too (although again with all of the wonderful options), but I'm no longer content with not understanding it.

@vr8hub ...

Right, I understood that (some things are so simple even I can get them). Without that option, eac3 would be transcoded to ac3. And with that option, ac3 is transcoded to eac3. (And the --aac-encoder was a dumb question, even for me; I was not paying attention.)

Actually, AC-3 will not be transcoded to E-AC-3 unless it's above the passthrough bitrate. And since the default passthrough bitrate is 640 Kbps, that never happens, by default.

Why is that? Basically because anything that can play E-AC-3 can also play AC-3 so there's no reason to re-transcode it. (Actually there is one "ooops" device out there that can play E-AC-3 but stupidly not AC-3. However, the manufacturer is trying to kill it. So we will not speak of it again. :) )

My question was that if the bitrate was higher than whatever was specified (or defaulted) on the --pass-ac3-bitrate option, what bitrate is it transcoded to? Does it use the --pass-ac3-bitrate ("convert anything above this pass-through rate to this rate"), or does it use the --ac3-bitrate ("convert anything above this pass-through rate to the --ac3-bitrate"). IOW, with --ac3-bitrate 384 --pass-ac3-bitrate 640, and a bitrate of 1536, is the 1536 transcoded to 384 or 640?

D'oh! Sorry, I misunderstood. That happens a lot, unfortunately.

It uses the setting for the --ac3-bitrate option which, by default, is 640 Kbps. But if you add --ac3-bitrate 384 --pass-ac3-bitrate 640 to your command line then an input bitrate of 1536 Kbps is transcoded to 384 Kbps.

And a hearty thank you for your patience. I actually (somewhat) understand all of the various audios out here in the real world. (IOW, I know the difference between TrueHD and DTS and AC3, etc. as it comes to a receivers, Blu-ray, etc.) What I have no grasp at all of is how all of this is handled and transcoded and used and abused in the transcode world. In my Handbrake GUI days, I avoided the audio tab; it had something about AC-3 and something about passthrough, but I didn't understand it and left it alone. I maybe should leave it alone now, too (although again with all of the wonderful options), but I'm no longer content with not understanding it.

And a hearty "you're welcome" to you sir! No worries.

Answering questions like this just comes with the job of being the lone insane autocratic project leader of a small-ass utility. :)

And thank god you understand the differences between the formats! Many of our users struggle with that because, as you well know, it's forking complicated out there.

But you're asking all the right questions to understand how it's handled. And, like I said, I don't mind. If anything, it clarifies my own thinking about it.

So, since now is the winter of your discontent, keep asking. :)

@donmelton

I don't have "Baby Driver (2017)"

You should rectify that, for the opening 10 minutes if nothing else

@samhutchins OK, now you have me curious. :)