Reconsidering audio

[samhutchins]

As promised, I've been noodling on audio options all week:

As it currently stands, the --audio-width option feels a little overloaded, as it combines a decision about track layout with a decision about audio format

I propose changing the --audio-width option (and consequently the default behaviour) in such a way that the format is not directly implied by the chosen layout i.e., try harder to pass audio if it matches the chosen track layout.

I also propose adding an option for choosing the format for particular track layouts: --audio-format stereo|surround=ARG, where ARG can be ac3, e-ac3, or aac

Other side effects: We should probably deprecate --prefer-ac3
We could use this as an opportunity to re-think the default track layout and make it stereo

Here's a table of the behaviour I'd expect by default, for the inputs I've seen ripping Blu-Rays and DVDs recently. It has the input at the top, and the layout option on the left. I've marked the behaviours that are different to now in italics

.	7.1 flac	5.1 AC3	2.0 PCM	2.0 AC3	1.0 AC3
width=stereo (default)	2.0 AAC	2.0 AAC	2.0 AAC	2.0 AC3 (pass)	1.0 AC3 (pass)
width=surround	5.1 AC3	5.1 AC3 (pass)	2.0 AAC	2.0 AC3 (pass)	1.0 AC3 (pass)
width=double	5.1 AC3, 2.0 AAC	5.1 AC3 (pass), 2.0 AAC	2.0 AAC	2.0 AC3 (pass)	1.0 AC3 (pass)

In other words: by default pass audio if it's AC3 or AAC below certain bitrates, if it matches the requested track layout. When transcoding audio is required, default to AC3 for surround and AAC for stereo, unless otherwise specified. This way the user can ensure stereo and surround tracks are in either AC3 or AAC (if their target playback device supports it).

The motivating use-case for me is that I've been ripping TV shows from DVD recently, and some shows have a 5.1 track and some don't, but they're all AC3. I don't want my TV shows in 5.1, so what I want to do is add --audio-width main=stereo to my command line, but that will transcode the 2.0 AC3 tracks to AAC which I don't want.

[lisamelton]

@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?

[lisamelton]

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

[samhutchins]

@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

[samhutchins]

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

[lisamelton]

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

[samhutchins]

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

[samhutchins]

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

[lisamelton]

@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?

[khaosx]

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

[lisamelton]

@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?

[lisamelton]

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

[lisamelton]

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

[lisamelton]

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

[rhapsodians]

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

[lisamelton]

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

[damorrison]

It’s probably a can of worms and a ton of work, but have you ever considered creating defaults based on target payback device? I.e an iPad Pro, nvidia shield, Plex on a tv, etc? Along the lines of the handbrake presets.

On Thu, 14 Feb 2019 at 21:32, Don Melton notifications@github.com wrote:

@rhapsodians https://github.com/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 sounds 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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/donmelton/video_transcoding/issues/254#issuecomment-463805967, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYJDX2VCLE_pIWQVTdME_F0Yjp4wtu6ks5vNdXSgaJpZM4a6UAF .

-- Kind regards, Dave

[rhapsodians]

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

[lisamelton]

@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!

[lisamelton]

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

[lisamelton]

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!

[rhapsodians]

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.

[lisamelton]

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

[rhapsodians]

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]

Perhaps extend the examples to include some of the scripts everyone probably has lying around too.

On Thu, 14 Feb 2019 at 23:54, Joe Hurley notifications@github.com wrote:

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! :-)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/donmelton/video_transcoding/issues/254#issuecomment-463850871, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYJDXx7b9KOvMrVJbvsPb9lcoY0pIvWks5vNfcggaJpZM4a6UAF .

-- Kind regards, Dave

[lisamelton]

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

[lisamelton]

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

[lisamelton]

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

[khaosx]

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

[lisamelton]

@khaosx Yeah, those options should still work fine.

And I do think an advanced per-track audio option would be handy. So don't give up on it!

[samhutchins]

@donmelton So for my stereo-only TV use-case, I'd do --audio-width all=stereo --copy-audio all, and it would copy stereo AC3 tracks but transcode everything else to AAC?

And if that's the case, how would one copy a flac track to the output, if --copy-audio has a fallback?

[samhutchins]

@donmelton And I agree about not changing the default track width behaviour, I think I got a little to carried away with in-a-perfect-world thinking

[lisamelton]

@samhutchins Good question! But I would think --audio-width all=stereo --copy-audio all would work the way it does now. At least for MKV output. Or maybe I'm misunderstanding you?

I think FLAC format gets copied now, again, for MKV output.

MP4 output has always been a clusterfuck, which is another reason I don't like it. :)

Once I get back to my development machine tomorrow I need to run a series of tests and actually map out what does happen, for both output formats. Then we can better answer these questions. I can't believe I don't know the answers off the top of my head.

[samhutchins]

So, just to bring it all back to the problem I was having that made me open this issue in the first place:

I have some TV shows, some of which have 5.1 audio and some of which have stereo audio. They're all in AC3 format though.

For a bunch of reasons, I'm not interested in preserving 5.1 for TV shows, so I want to make the output stereo. If I add --audio-width main=stereo to my command, 5.1 AC3 is transcoded to 2.0 AAC which is great. But the 192kbps 2.0 AC3 tracks are also transcoded to AAC, which feels a little silly to me and I'd rather that didn't happen. At the moment, I have to inspect the input and add --prefer-ac3 to my command if the input is stereo AC3.

My original suggestion, of making --audio-width pass audio of matching layouts unless the input is something other than AC3, E-AC3, or AAC means my desired behaviour happens. Stereo AC3 audio is copied, surround AC3 is transcoded.

Adding the --audio-format argument also covers a use-case you mentioned in my mixdown pull request, allowing users to choose AAC for surround tracks, plus it allows users to preserve the current behaviour of transcode-video and force all stereo tracks to be AAC.

[lisamelton]

@samhutchins D'oh! I completely misunderstood you all right. Sorry about that.

Solving your problem would definitely change the behavior of --audio-width main=stereo then. And getting the current behavior of always transcoding to AAC would require --audio-format stereo=aac, right?

I realize now this makes my preferred behavior an even more complicated command line. :) Not sure if I'm as enthusiastic about that now.

[lisamelton]

@samhutchins How can we design this so you get your desired behavior as an option and leave --audio-width main=stereo working the way it does now? Is that possible?

[lisamelton]

@samhutchins Then again, maybe I should just get over my preferred behavior. :) After all, it's better to not transcode when you don't have to. However that does mean having any AC-3 tracks, even stereo ones, requires Plex to dynamically transcode them for most of my Roku configurations.

[lisamelton]

@samhutchins Thinking about it more, doing less transcoding and more passthrough is a good thing. That's pretty much been my mantra from the beginning. So you are right. But I do want to make sure we have a way to get that old behavior. Hopefully --audio-format stereo=aac would do that.

[lisamelton]

@samhutchins BTW, I'm looking at the code in the prepare_audio method of transcode-video and I don't think this all that complicated to implement. The real work would happen in the add_surround and add_stereo inline methods.

[lisamelton]

@samhutchins And, hysterically, your functionality matrix actually makes part of the code simpler. :)

[khaosx]

@samhutchins Hold my scotch, I'm going to make a vein pop out in Don's temple.

Hey, we need "--addTrueHD" and "--addDTSHD" switches too.

I'll see myself out.

[lisamelton]

@khaosx LOL! 😂

[lisamelton]

@samhutchins I'm implementing this and I just hit a snag. What happens if a track is double width and the format for surround and stereo are the same? Do we just output a single track?

[lisamelton]

@samhutchins Now that I'm in the middle of the implementation, I think there may be an easier way to get what you want without adding a --audio-format option. Or maybe narrowing that somewhat. Because that's actually complicating other things. Basically you just want to passthrough stereo and mono AC-3. It's a limited form of --prefer-ac3.

[lisamelton]

@samhutchins OK, I've implemented the behavior you want. Basically it replaces this line in the add_stereo inline method:

        if copy or (info[:format] =~ /^AAC/ and info[:channels] <= 2.0)

...with:

        bitrate = info[:bps].nil? ? 640 : info[:bps] / 1000

        if copy or
            (info[:channels] <= 2.0 and
            (info[:format] =~ /^AAC/ or
            (@samhutchins_mode and
            ((@ac3_encoder == 'ac3'  and info[:format] == 'AC3') or
             (@ac3_encoder == 'eac3' and info[:format] =~ /^(?:E-)?AC3$/)) and
            bitrate <= @pass_ac3_bitrate)))

...where @samhutchins_mode is a placeholder for the actual option. :)

Essentially, this borrows logic from the add_surround inline method to cover all the encoder and bitrate passthrough requirements.

For the short term, maybe we just replace --prefer-ac3 with a similar option which can cover both sets of functionality? That way we don't change any default behaviors.

[lisamelton]

@samhutchins BTW, that @samhutchins_mode variable is just a boolean, obviously. :) So, technically, we could default it to true and make an option which restores the old behavior. Seriously, I could go either way on this.

[lisamelton]

@samhutchins Maybe we could call the option something like --allow-ac3-stereo? Or maybe a --stereo-format aac-only|allow-ac3 option?

[samhutchins]

I think --samhutchins-mode is a great name.

Would changing --prefer-ac3 so that it didn't force the audio-width to be surround also achieve this behaviour?

[samhutchins]

I'm implementing this and I just hit a snag. What happens if a track is double width and the format for surround and stereo are the same? Do we just output a single track?

So, if the input is a 5.1 AC3 track, and the user's added --audio-format all=AC3? Assuming double width by default?

I'd expect it to pass the 5.1 AC3 track, and also transcode it to a 2.0 AC3 track

[samhutchins]

The core principle, if you will, behind my original suggestion was to try and separate decisions about track layout (i.e., track width) from track format (e.g., AC3, AAC, etc.)

So 5.1 shouldn't mean it's AC3, it could be AAC (chromecasts can handle that, AFAIK)
2.0 shouldn't mean it's AAC, it could be AC3.

You raise an interesting point about the default playback capabilities of Rokus, I'd forgotten that they can't decode AC3. As I recall, I actually used exactly that as an argument against making the --prefer-ac3 option the default behaviour. I think that argument is equally valid here, so I think you're right to try and find a way to implement this "samhutchins-mode" behaviour without changing how --audio-width works.

My original proposal is very broad, and gives a lot of flexibility in the way audio is handled, but perhaps it needs a little more thought.

---

Looking through the code this morning, I think that if --prefer-ac3 didn't force --audio-width all=surround, and the logic in the prepare-audio method was changed, I'd be able to get the behaviour I want without fundamentally changing the way audio works in transcode-video

[lisamelton]

@samhutchins ...

I think --samhutchins-mode is a great name.

Of course. :)

Would changing --prefer-ac3 so that it didn't force the audio-width to be surround also achieve this behaviour?

Oddly enough, no. That's because it's the surround path that has the logic to copy AC-3 tracks.

So, if the input is a 5.1 AC3 track, and the user's added --audio-format all=AC3? Assuming double width by default?

I'd expect it to pass the 5.1 AC3 track, and also transcode it to a 2.0 AC3 track

I would certainly want that behavior, i.e. double widths continue to be one multichannel AC-3 track and one stereo AAC track, but that goes against the semantic meaning of "all" in "--audio-format all=ac3". Maybe the right answer is not to follow my recommendation of having "all" as a format selector because it implies application to double widths? (Obviously that's what was happening to me last night. :) )

Which means that if we add the option, I would simply explain it this way:

    --audio-format surround|stereo=ac3|eac3|aac
                    set audio format for surround or stereo widths
                      (default for surround: selection from `--ac3-encoder`)
                      (default for stereo: aac)
                      (can be used multiple times)

How does that look to you?

Hmmmm, thinking about it now, that makes a lot more sense. And avoiding the double width path in the code certainly simplifies implementation.

The core principle, if you will, behind my original suggestion was to try and separate decisions about track layout (i.e., track width) from track format (e.g., AC3, AAC, etc.)

Yes, and I like that principle!

So 5.1 shouldn't mean it's AC3, it could be AAC (chromecasts can handle that, AFAIK) 2.0 shouldn't mean it's AAC, it could be AC3.

Dealing with the future is exactly what attracted me to your plan. So I think we go back to that. My apologies for mucking this up by being confused.

You raise an interesting point about the default playback capabilities of Rokus, I'd forgotten that they can't decode AC3. As I recall, I actually used exactly that as an argument against making the --prefer-ac3 option the default behaviour. I think that argument is equally valid here, so I think you're right to try and find a way to implement this "samhutchins-mode" behaviour without changing how --audio-width works.

Sweet. I agree, thinking about it now.

My original proposal is very broad, and gives a lot of flexibility in the way audio is handled, but perhaps it needs a little more thought.

Actually, I think you were on the right track here. I was the one having a brain fart. :)

Lemme take another pass at a implementation of the new description of --audio-format (provided that you think it works, too) and we'll see where that takes us.

I'll be on the road and unresponsive for the next several hours (traveling across California), but I should be able to get back to this in the late afternoon of my time zone. I'll check back here when I return.

Thanks again for your patience and clear thinking!