Add --name to standard help

[vr8hub]

I realize this is all a matter of opinion, and less is better, and design is all about saying "No", and all the other things.

Nevertheless, I would suggest that "--name" be added to the standard help. I didn't see an option for it when I did --help, and I also didn't notice that there were other options for help (more, full), because they were at the very end where I wasn't looking for the information. (I piped it to less, so I only read as far as I needed for what I was looking for.) Yes, I'm an idiot, but that's not news, and it's also a common affliction.

The output of a rip "normally" (is there anything "normal" about any of this?) contains a track# (Movie_Name_t00), and we rarely/never want that in the transcoded file name. Maybe some/most people rename the ripped file before they do the transcode and this isn't an issue. I don't know, but either way, I don't. So I always want to rename the transcoded file. I don't think that's uncommon. Since that means specifying the name is a commonly used function, I would say that it should be in the most commonly used help, which is the default help.

As with some of my other suggestions, this no longer affects me, since I now know it's there. But I suspect other new users might to have the same problem, and thus having it in the default help would make things more helpful for them.

On a related note, the ffmpeg command-line that's output shows a metadata:g title=<the output filename>. I've confirmed that the string specified in --name is also used there. But shouldn't the title be the --name without the extension, i.e. just "Movie name", not "Movie Name.mkv"? And ffmpeg help indicates the "basic" command line is ffmpeg -i infile outfile, but there's no outfile specified on the other-transcode generated command line, even with --name. (I'm just doing a -n since I've already done the transcode.)

(And since I'm here, what are the :g and :s:v and :s:a:0 things on the various metadata options? I've looked at the ffmpeg help and online documentation, and both just reference "metadata string"; I don't see any mention of colon options anywhere.)

[lisamelton]

@vr8hub The --name option was designed to make it easier to write automated test rigs such as those that @khaosx and @rhapsodians were working with during development. And it was designed for those people bold enough to use the same directory for both input and output. I never intended the --name option to be a common user feature. Which is why it's buried in --help more.

I believe that choosing either an input or an output name is the province of the mv command. If "Movie_Name_t00.mkv" is a troubling, then a user should just change it before they transcode. Or change it afterwards. It makes no difference because the name of the file has no effect on the contents of the file.

And the --name option has no effect on the metadata in the output file. I think you're misinterpreting -metadata:g title= sample.mkv at the end of the FFmpeg command line that I generate. Notice the space between the = and sample.mkv there. I'm not setting the title equal to the filename. I'm setting the title to an empty string. And sample.mkv is the output filename.

As to the use of "colon options" in the generated FFmpeg command line, these are required for mapping input streams to output streams or designating stream types. And all of that nomenclature is actually in the documentation, although I will admit that documentation is often hard to fathom.

[vr8hub]

Every command (and app) on the planet that produces output has a way to name that output. It is the definition of "common," so much so it can't even be classified as a "feature." Why would I issue two commands when what I want to do can be done in one? That's silly and user-hostile. And you're neither. :) So we'll agree to disagree.

[lisamelton]

@vr8hub A fair assessment, sir, on both points. Thank you.

So, would a real --output option, which could specify a complete path+name+extension combination, be better?

I have been against adding such a feature because it's gotten users of transcode-video into trouble before. But I am willing to discuss it again.

[vr8hub]

Well, now we have two issues. (Reminds me of a regex meme…)

The ability to specify an output filename is a standard function of any software that produces output. There should be a way to do that (there is), and the way to do that should be clearly documented (it is and it isn't, hence this issue).

The ability to specify the location of that filename is a little hazier. I would personally say that should be part and parcel of the output filename. Again, I can't think of a piece of software that produces output that doesn't let me tell it where to put the output. I can recollect software that does that with two different parameters, but that's always struck me as making things easier for the programmer rather than the user, and I always side with the user in those situations. (Computers are supposed to make things easier for the people that use them, not the people that program them. I say that as a person who occasionally has to program them.)

What that parameter is called, e.g. name vs output, etc., I have no strong feelings about. -o and/or --output are pretty common, but certainly not ubiquitous (e.g. ffmpeg itself doesn't use them).

Now, then we have users who do dumb things (this set includes me). For example, I initially ran the other-transcode in the source directory. Before I knew there was a --name option. Fortunately, you or ffmpeg or something told me the output filename already existed, and I didn't lose my input file. Which was kind.

And that's what should happen, where possible. If a user specifies the same name for input and output, then kind software will warn them of that before it gets started. Not all software, just kind software. You are (generally) kind and you produce kind software. Yes, I know that resolving input and output filenames can be hairy, but there's software for that. (I had to do something similar once upon a time when I wrote a SQL module that copied the contents of a table from one table to another. I had to jump through all kinds of hoops to make sure that the database/schema/tablename resolved to something different for source and destination.)

If users go out of their way to workaround the kind software and still shoot themselves in the foot, well, then, I don't have a lot of sympathy. "Hey, I told you a) guns are dangerous, b) you shouldn't point them at yourself, and c) you shouldn't pull the trigger if you ignore a) and b). I feel bad for your missing toe, but that's on you." I have done some of that shooting before, and I owned it, I didn't yell at the software maker.

[lisamelton]

@vr8hub It's other-transcode that's doing the warning if the output filename is already in use.

But that was a trick question I asked about --output. My apologies. And that's because specifying a full path+name+extension combination wouldn't work for other-transcode. In fact, it has exactly the same limitation/problem/bug that the current --name implementation has now.

You see, the other-transcode tool allows multiple inputs. So specifying a single output name will work for the first output but fail for any after that.

This is another reason I'm burying the --name option. :)

[vr8hub]

(Thanks for the warning, it saved me from having to re-rip Dark Knight!)

Oh my. So. Many. Problems.

Help has…

• No mention of it taking multiple inputs. (If you're depending on that … after [FILES] to communicate that, it didn't work.)
• No mention of what it's doing with those multiple inputs. Is it combining them? Is it creating an output for each? Where is it creating an output for each? What if we don't want all of the outputs in the same place?
• No mention of what --name does if multiple inputs are specified.

This violates "least surprise" in oh so many ways.

I'm going to fall back to the "agree to disagree." :) This is your software, you get to do it the way you want to do it, and we can use it or not. I now know the --name is there, I'm never going to specify multiple inputs, so I'm good to go. Thank you for your patience with an opinionated user. :)

[lisamelton]

@vr8hub Well, I hate to break it to you but transcode-video takes multiple inputs and is documented the same way. And the ellipsis is commonly used to document that usage in the --help output of other tools like grep, sed, chmod, etc.

So, with this being a near-universal idiom for command line tools, I won't be changing that.

As to not documenting what --name does if multiple inputs are specified, so far nobody—not even any of the project contributors as far as I know—has noticed that or commented to me about the behavior. So, for now, I'm fine with the error message users receive when the second input is processed.

But it does make me seriously consider removing the --name option altogether because, like you, I like things to be consistent.

[vr8hub]

Well, I hate to break it to you, but I didn't know that, either. :) So the documentation is two for two in not communicating very well.

The problem isn't with the ellipsis, the problem is with no discussion of multiple inputs anywhere in help or the readme.

You and the project contributors have "the curse of knowledge"; you know too much. (Chip/Dan Heath's Made to Stick relates a story about a tapping test study. The basics are covered here. I am guilty of this several times a day, usually with my wife. But at least now I'm (sometimes) aware of it. :) )

I like things to be logical, easy to use, easy to figure out ("least surprise"), and probably a couple of other things before I get to consistent. Consistency is the least of the issues here. :)

Allowing multiple inputs without allowing multiple outputs is, IMO, a fundamental design flaw. (And I wouldn't fix it by allowing multiple outputs, I'd fix it by not allowing multiple inputs.) Please don't exacerbate that by not allowing the people who don't use multiple inputs to be penalized for that flaw.

I'm sorry I brought the whole thing up. Let's go back to arguing about how bad The Rise of Skywalker was.

[lisamelton]

@vr8hub If allowing multiple inputs without allowing multiple outputs is a design flaw, then I think we'll have to throw out most command line tools. :)

And, yes, I'll close this now so we can argue about "Star Wars" sequels in a different issue. :)