FEATURE REQ: Include Audio Track ID in Preset

[Casemon]

Scenario is this, have presets for single and dual audio ripping.

The dual audio preset remembers that I want 2 audio tracks, but it doesn't remember that I want the 2nd audio track to be audio track ID1 (1st audio track is ID0) DESPITE AUDIO TRACK ID1 EXISTING.

Instead, have to click the preset, then go into audio settings, then click on the track ID and manually change it to 1 for every file; sort of defeats the point of presets in this context.

Easy to handle "no audio track ID0 found" cases just as HB already does with mono-stereo setting; IOW if track ID0 is not found and the preset is asking for it, just use the next lowest audio track ID.

That said, great app guys; awesome work all around!

Long live Handbrake!

[Deleted User 11865]

HandBrake does not support multi-audio workflows (except manually). That's why the audio track number and the audio track language are NOT saved to presets. The track is automatically selected from the language set in preferences instead.

This isn't going to get implemented either. There's just no way to guarantee that the audio track numbers will correspond to the same audio track or language across multiple sources.

[Casemon]

Sorry to hear that you cannot make it work. Also, forget about language, no one is talking about language.

From here, it seems pretty straight forward (in pseudo code):

Code: Select all

If (sourceHasAudioTrack(1) && currentPresetWantsAudioTrack(1)) {
// set audio track value to preset id
}
else {
// do what is done currently
}

If you don't mind answering, what in that logic would change if cross platform or multiple sources? Track 0 is always track 0 no matter what the source is.

[s55]

This would only ever work for sources which have the same layout. This is an edge case scenario.

IF you encode id's 0 and 1 for one source, doing the same for another source will likely end up with you encoding the wrong tracks for the next source.

[Casemon]

This would only ever work for sources which have the same layout. This is an edge case scenario.

IF you encode id's 0 and 1 for one source, doing the same for another source will likely end up with you encoding the wrong tracks for the next source.

So how is the current drop down list of available audio tracks populated? Is that not consistent between systems?

Seems whatever method is used could work off the current method of populating the available audio track list to eliminate 90% of such consistency issues.

[s55]

The list is populated from the source file. Different sources have different tracks. (and therefor, different track id's )

[Casemon]

I think both attempts to address my feature req have actually been in answer to an entirely different idea.

I don't want Handbrake to try to second guess the source, or anything meaningful like that, i just want presets to store literal track ids, and load it if the given track id1 exists...

Not talking about language, not talking about the content of that track, just if there's more than 1 track, and the preset asks for it, then fill the variable.

Not any more complicated than that. Such would enhance the workflow of the _majority_ of users who rip with more than 1 track in *most* cases (not all, ok, but who cares? user can still manually verify that it's all good before starting the job, as they do today).

Would be very surprised if this wasn't possible, as it's pretty basic stuff.

[s55]

There is a consequence to your idea, and that is it'll really confuse people with completely inconsistent results.

DVD 1:
1 English
2 English (Directors Commentary)
3 Dutch
4 French

DVD 2:
1 English
2 Dutch
3 French
4 English (Directors Commentary)

DVD 3:
1 French
2 Dutch
3 English
4 French (Directors Commentary )


Now, store id's 1 and 2 in the presets and when you reload them you get the following as output:

DVD 1:
1 English
2 English (Directors Commentary)

DVD 2:
1 English
2 Dutch

DVD 3:
1 French
2 Dutch

There is nothing consistent about this. All it's going to do, is confuse and frustrate people. It's better to force people to check the correct track, than to try and fail badly at selecting it based on this idea of an ID.
It gets even worse when you start dealing with dummy / fake / out of order tracks and duplicate tracks.

[Casemon]

As a user, I disagree.

Adding what you present is not a valid case, as *the feature req isn't about language*, it's about track IDs. The feature request isn't "save language choices in presets" it is "save track id's with presets". You keep trying to say it's about language, when it is not.

Make it clear that the track ID not language is saved in the preset, something most users already understand & know, and your whole reason for resisting this obvious enhancement becomes a non-issue.

I suggest that saving track IDs with presets & informing people that track IDs are inconsistent between sources is more beneficial than forcing people to select the track IDs manually and propagating their false assumption.

Do you still disagree?

[s55]

You realise that a track id of say 2, is just a random track right? You have no idea what you're going to get.

[Casemon]

Well not "no idea"; we're talking audio tracks for a specific title in a source, so it's going to be some form of audio.

HB should be able to say ok, if this title has 2 audio tracks, and user clicks on a preset that uses 2 audio tracks, fill them with whatever IDs are saved in the preset. Same for 3 or more.

This empowers users to create presets that match their sources better, reduces annoying repetitive manual tasks, and gives greater functionality to presets in the form of improved functionality.

Sure the down side is some people might use the app other than designed, which is something that cannot be improved by avoiding enhancements to the existing interface.

Example:
Preset1's audio options includes 2 audio tracks (any format settings); audio track 1 has ID of 0, audio track 2 has ID 1.

some titleA has 2 audio tracks:
Preset1 fills sequentially, as specified in preset.

some titleB has 1 audio track:
track 1 is ID0, track 2 is set to none (currently HB just fills both with the same track redundantly, which is annoying and find it hard to imagine a frequent case where this is the desired behviour).

Another example:
Preset2's audio options includes 3 audio tracks (any format settings); audio track 1 has ID of 1, audio track 2 has ID 0, audio track 3 has ID of 3.

some titleC has 3 audio tracks:
Preset fills audio options as expected; track 1 is ID 1, track 2 has ID 0 and track 3 has ID 3.

some titleD has 1 audio track:
track 1 has ID 0 & track 2 & 3 are set to none.

[Deleted User 11865]

Adding what you present is not a valid case, as *the feature req isn't about language*, it's about track IDs. The feature request isn't "save language choices in presets" it is "save track id's with presets". You keep trying to say it's about language, when it is not.

That's the whole point. Track IDs are random and inconsistent, and would cause the wrong tracks to be selected in most workflows. We're not going to make something that serves some sort of edge case scenario the default. If anything, languages should be saved in the preset, not track IDs.

[Casemon]

Rodeo, think you're looking at this from a view other than "source centric" which is maybe why it's hard for you to grasp. And please for the love of god forget about language; apples & oranges my friend.

It is *accepted* that sources are different, so logically the tools should be designed with that in mind and empower common tasks while still enabling flexibility (manual changes still possible).

This isn't some edge case scenario, this is improving the software workflow to behave as one would expect knowing full well that sources are different.

The current behavior of saving a preset with 2 audio IDs, & restoring the preset only to have both IDs be the same value is NOT good design.

[Deleted User 11865]

HandBrake is not designed to work in the way you would like; we're not going to break existing, working workflows to accommodate a retarded, useless idea like yours. Now stop wasting our time.

[Casemon]

Hmm I'm a long time HB user who has ripped 100s if not 1000s of sources (who also happens to be a software developer of over 15 years) and you're calling my idea retarded because you're confusing it with something else and contributing to further user misunderstanding!? And you suggest it "breaks existing workflows"; how's that precisely?

Wow... just wow.

What's your role on this project? Squash any idea that improves the app but doesn't fit into your (obviously) narrow conception of what it should be?

I know you're not paid for this, and am sincerely happy you're contributing your time to open source, but really man, this is not the way to go if you want to create good software. Insult users who take time to provide feedback and try to help when you obviously confuse 2 issues? Wow.

Not unless you want to help open the door for some other app whose devs understand that concessions shouldn't be made to the developer's whim and that good design doesn't end with what the developer prefers; it is the users who are the "client".

I know HB is the best game in town for the moment, but with attitudes like yours, it won't be for long. Sorry.

Your attitude & behavior here reminds me of a question:
Why is it the most narrow-minded people are the first to get in the "i want to make decisions!" line?

Food for thought in any case! hahahahaha

Won't waste time trying to help improve your app anymore. Thanks.

[Deleted User 11865]

Hmm I'm a long time HB user who has ripped 100s if not 1000s of sources (who also happens to be a software developer of over 15 years) and you're calling my idea retarded because you're confusing it with something else and contributing to further user misunderstanding!?

There is no confusion. I fully understand that languages and track IDs aren't the same. But language matters because:

1) currently HandBrake selects the source audio track based on language. Implementing your request would completely change that behavior.

2) people select audio tracks based on their content, and language is related to a track's content.

And you suggest it "breaks existing workflows"; how's that precisely?

s55 already gave an example:

DVD 1:
1 English
2 English (Directors Commentary)
3 Dutch
4 French

DVD 2:
1 English
2 Dutch
3 French
4 English (Directors Commentary)

DVD 3:
1 French
2 Dutch
3 English
4 French (Directors Commentary )


Now, store id's 1 and 2 in the presets and when you reload them you get the following as output:

DVD 1:
1 English
2 English (Directors Commentary)

DVD 2:
1 English
2 Dutch

DVD 3:
1 French
2 Dutch

In that scenario, tracks are selected based on track ID (your request) instead of language (current behavior). As you can see, for two of these three DVDs, the user will have to change the tracks manually to get the two tracks he wants. No improvement here.
Plus, with the current behavior, the first track would have been selected correctly* - the user would only have had to change the second track.

Now, your behavior makes sense if you're encoding all episodes of a TV series where the DVDs' track layouts match throughout a season (i.e. it will likely select tracks that make sense and won't need to be manually changed); but presets are meant to be more versatile than this.

And even then, the numbers of tracks and track ID of the track you want may change even from an episode to another. Example:

Code: Select all

Episode 1 (with commentary):
Track ID 1 English
Track ID 2 English (Director's Commentary)
Track ID 3 Spanish
Track ID 4 French

Episode 2 (no commentary):
Track ID 1 English
Track ID 2 Spanish
Track ID 3 French

This may be less common, but can happen. Say you want English and Spanish audio tracks, you'd have to select track IDs 1&3 for the first episode, and track IDs 1&2 for the second episode. This can't be saved in a preset.

The problem is that you can't know for sure which track ID will correspond to the track you want, so in most cases you can't reliably choose a track based on ID and you'll always have to check and possibly change the audio selection before encoding.

While you also have to check and change the source tracks manually if you want to include multiple different tracks from the source under the current language-based system, said system works very well for people who only include one audio track from the source (i.e. most people), whereas yours doesn't.

Not unless you want to help open the door for some other app whose devs understand that concessions shouldn't be made to the developer's whim and that good design doesn't end with what the developer prefers; it is the users who are the "client".

1) there are no clients or customers here, only users

2) this is a developer-driven project

The developers are HandBrake users, too. Most features were added are added because a developer needed and/or wanted to add it; sometimes patches provided by other people are included too.

Users suggestions are considered (s55 did take the time to read your request and think about it for a moment), but if developers think it's a bad idea or have no interest in it, it's not going to happen. Also, if the developers come to an agreement and formally reject your feature request (which technically hasn't happened - yet), there's no point in arguing any further. Their decisions are final.

I know HB is the best game in town for the moment, but with attitudes like yours, it won't be for long. Sorry.

Doesn't really matter. Being "the best game in town" and having lots of merry users might be nice, but it's not the first priority.

Your attitude & behavior here reminds me of a question:
Why is it the most narrow-minded people are the first to get in the "i want to make decisions!" line?

Says the open-minded person who doesn't give a damn about the most common usage scenario (one source track with one or two output tracks).

*The current system makes the following assumptions:

• The main audio track comes before the commentary
• The multichannel surround track comes before the 2-channel mixdown (if any)

Therefore HandBrake selects the first track matching the language specified in preferences.
While these aren't necessarily always true, they're often true and selecting the track this way is nowhere nearly as random as selecting a track based on the ID.[/size]

[nexradix]

I disagree with the original poster's request and attitude, but he/she did inspire in me a related idea: what about saving audio tracks in the presets based on the track label, rather than id? It seems Handbrake is able to provide labels for the audio tracks of most DVDs. What about storing audio track info in the preset using the label and a wildcard -- for example: add any tracks containing "english*", which would grab "English" and "English (Director's Commentary)"? Or "*commentary*" could grab any tracks with the word commentary in the label. That seems to deal with the fact that audio tracks are almost always in different (and often irrelevant) orders.

Of course I don't know if such a task is even feasible, as I don't know how (or when in the process) Handbrake determines the audio track labels. And of course not all discs even get labels. But a thought nonetheless.

[JohnAStebbins]

I disagree with the original poster's request and attitude, but he/she did inspire in me a related idea: what about saving audio tracks in the presets based on the track label, rather than id? It seems Handbrake is able to provide labels for the audio tracks of most DVDs. What about storing audio track info in the preset using the label and a wildcard -- for example: add any tracks containing "english*", which would grab "English" and "English (Director's Commentary)"? Or "*commentary*" could grab any tracks with the word commentary in the label. That seems to deal with the fact that audio tracks are almost always in different (and often irrelevant) orders.

Of course I don't know if such a task is even feasible, as I don't know how (or when in the process) Handbrake determines the audio track labels. And of course not all discs even get labels. But a thought nonetheless.

Not a completely idiotic idea. But it has some usability problems. A general purpose free-form edit field that allows regular expression entry is definitely only a power user feature. So it would have limited usefulness to most folk. If you wanted to make it more accessible, you would have to add multiple choice selection popups for each of the major categories you want to allow filtering on. This many controls would warrant their own popup window. I don't think the feature is important/useful enough to justify the complexity. Personally, I wouldn't use such a feature. This is where "developer interest" kicks in. There are potential new features I would much rather spend time on. Like my current project to allow transcoding and passthru of truehd audio direct from BD images.

HandBrake developers are rarely motivated by user or "client" desires. Speaking for myself, I contribute features that are a benefit to *me*. It just happens that what is useful to me is usually useful to others. None of us get paid for our efforts. So if you want something, you need to be persuasive and patiently plead your case. In the end, you may lose anyway, but a good attitude (even in the face of short tempered developers) will get you further.

[arcasinky]

At the risk of resurrecting a dead horse...

I stumbled on this thread because the OP's request is similar to a feature that I've often wished HB offered but perhaps the nomenclature is different. I, too, would find it useful to be able to tell HB to select the audio track to encode by ID (not track number). For example, I speak English so I'm usually interested in encoding the audio track tagged with ID 0x80 (English) no matter if that's the first or tenth audio track on the disc/file to be encoded. So far as I can tell, there seems to be no way to tell HandBrake or HandBrakeCLI to do this.

So prior to encoding a disc or file, I typically have to make a trial run with HB for a few seconds (or run mplayer -identify -frames 0) and look at the log output in order to identify which audio track # is tagged with audio ID 0x80. Then I can feed "-a <track #>" to HandBrakeCLI and encode the desired audio track.

It would be nice if HandBrakeCLI had an option that lets me specify the audio track ID that I'm interested in. Perhaps a --aid option that's similar to the -a option with the exception that instead of track ordinal numbers as arguments, the user can specify track audio IDs...

ie. HandBrakeCLI -v -Z "High Profile"...-aid "0x80,0x80,0x80" -o foo.mkv

I initially thought that I could accomplish what I wanted by using the --native-language and --native-dub options. And maybe that would work if the audio tracks had metadata that includes the 2- or 3-character ISO language codes but those two options seem to have no effect if the only metadata available is the numeric AID value...

Anyway, apologies if I've rekindled an old argument...

[Edited to fix grammar]

[JohnAStebbins]

Audio track ID 0x80 is *not* guaranteed to be the english track. What gave you the impression that it would be? Every foreign language DVD I've seen uses 0x80 for the native language track of the disc. e.g. german version of some movie will have the german track first with id 0x80. The tracks are usually ordered by id such that the native language of the target market is first. The id is just as arbitrary as the track number.

[Deleted User 11865]

Audio track ID 0x80 is *not* guaranteed to be the english track.

Not to mention, audio track ID 0x80 is by no means guaranteed to exist. 99% of sources just won't have any track with this ID.