[MPlayer-DOCS] [PATCH] mplayer advanced audio usage guide

[The Wanderer]

Corey Hickey wrote:

> I have a new patch attached with most of your concerns addressed. See
> below for notes.
> 
> You can run a diff between this diff and the last diff if you want to
> see the differences. They're a little bit polluted because I
> re-wrapped sometimes, but I'd prefer to keep the wrapping nice until
> this gets committed.

I don't see a new patch, actually.

I tend to leave the wrapping alone when doing things like this, but I
can understand wanting to keep things neat; it gets neglected often
enough in practice.

> The Wanderer wrote:

>> Not sure if it's advanced enough to be worth considering, but it
>> might be nice to have an explanation - and, more importantly, a few
>> examples - of the use of "-softvol-max" and related options
>> somewhere; I'm not sure it's sufficiently comprehensible for the
>> ordinary user (I had some difficulty getting it clear myself, when
>> the options were first implemented).
>> 
>> (Then again, if it's *that* important (and would belong anywhere
>> near here), the onus would presumably be on me to write the
>> addition... we'll see if I wind up being too lazy or not.)

Did you intend to come back and reply to this, but forget, or did you
jut not notice that you hadn't snipped it?

(Because I've done both, in the past... and the former at least can be
corrected after the fact.)

>>> +Most DVDs and many other files include surround sound.
>>> +<application>MPlayer</application> supports surround playback but does not
>>> +enable it by default because stereo equipment is by far more common. To play a
>>> +file that has more than 2-channel audio use <option>-channel</option>. For
>>> +example, to play a DVD with 5.1 audio:
>> 
>> I'm not 100% happy with the commas (or rather, lack thereof) in the
>> second sentence, but it's not nearly as bad as many things I've
>> let go by for lack of better solutions in the past.
> 
> I'm pretty sure that sentence is correct. It's been long enough since
> English class that I don't remember very many grammar terms; I have
> to look them up and I could be wrong. There are a few places I see
> where you might be looking for a comma:

If you still remember what to search on, you're probably ahead of me in
that respect. ^_^ Except in a few areas, I primarily operate in terms of
What Seems Right To Me, and occasionally overrule myself by what I
remember of English grammar; however, I tend to give "doesn't seem
awkward" and its ilk a higher precedence than "formally correct" when
nothing which satisfies both criteria can be found.

> * after "playback"
> 
> A comma may be used, and is usually recommended, when a coordinating
> conjunction joins two independent clauses. "Does not enable it by
> default..." is not an independent clause; it makes no sense by itself
> because it has no subject.
> 
> * after "default"
> 
> "stereo equipment is by far more common" provides an explanation for
> the rest of the sentence, so it is a dependent clause. Since the
> dependent clause comes at the end, a comma is not necessary (as
> opposed to this sentence, in which the dependent clause precedes the
> independent clause).

I considered both of these, actually, but each of them introduces
problems - what I might call "flow problems", except that there's an
entirely unrelated type of problem which also naturally goes by that
name - which are not present without it; inserting commas in both places
is worse, because "but does not enable it by default" is not a
sufficiently independent fragment that it should be set apart in that
way.

(The specific problems which would be introduced, and for that matter
perhaps the problem which would be addressed, are a matter of "pausing
in the middle" vs. "getting it all out in one metaphorical breath"; I'm
not aware of any formal rules governing the indication of pauses,
physical and conceptual, in sentence construction, but I've spent
considerable time thinking about the issue - to the point that I'd
probably consider it my area of grammatical specialty.)

The sentence as it stands falls into the negative side of the "all one
breath" category, and I prefer to avoid those when I can (especially
since they tend to lead towards run-on sentences), but sometimes it
isn't possible to come up with a good alternative.

> * surrounding "by far"
> 
> I intend "by" and "far" to be an adjunct rather than a parenthetical
> statement. If I had commas there they would interrupt the flow of the
> end of the sentence.

I agree entirely. The only change I considered suggesting there was to
drop the preceding "is", and I decided against that.

> Please don't take this as me trying to out-grammar you. :) I looked a
> few things up to see if I was right or not and wrote down what I
> found.

In formal terms, that puts you about even with me, if not ahead. ^_^ I'm
just glad to see someone else taking thought for these kind of issues,
even if we don't necessarily always agree with one another.

>>> +DVDs usually have surround audio encoded in AC3 (Dolby Digital) or DTS
>>> +(Digital Theater System) format. Some modern audio equipment is capable of
>>> +decoding these formats internally. In this case
>>> +<application>MPlayer</application> sends out the original, undecoded audio data.
>>> +This will only work if you have a S/PDIF (Sony/Philips Digital Interface) jack
>>> +in your sound card.
>>> +</para>
>> 
>> I'm not entirely happy with "In this case" vs. "sends" here, but
>> I'm not sure quite what the problem is or how to fix it. It's not
>> intolerable, it's just not ideal.
> 
> Well, the sentence isn't very accurate anyway. I'll change it to: 
> "MPlayer can be configured to relay the audio data without decoding
> it."

That works.

[S/PDIF]
>> unless that term is in fact pronounced beginning with the
>> teeth-together "sss" sound, the preceding indefinite article should
>> be "an".)
> 
> I've only heard it pronounced by a couple people; they both say
> "spidiff". I can't find any consensus from google, so I'm leaving it
> alone for now.
> 
> http://stereos.about.com/cs/glossaryandtools/g/aesebu.htm
> http://66.102.7.104/search?q=cache:4JMN35BM75cJ:dcto.duderesearch.com/forums/search.php%3Fdo%3Dfinduser%26u%3D5713+spdif+pronounce&hl=en
> http://www.hardcoreware.net/reviews/review-228-1.htm

Hmm. I'd have just pronounced each of the letters individually,
"ess-pee-dee-eye-eff" - as a matter of fact I think I've done that just
recently. Still, I rarely have occasion to use the term, as I'm not
remotely an audiophile; it's entirely possible I'd have gotten it wrong.

>>> +If your audio equipment can decode both AC3 and DTS, you can enable passthrough
>>> +for both formats. Otherwise, you can specify either one.
>> 
>> Sure you don't mean "just one" or "only one"? Saying "either" makes
>> it sound like you can pick whichever one you want, which is
>> certainly not the case unless your hardware is *really* weird.
> 
> "If your audio equipment can decode both AC3 and DTS, you can safely
> enable passthrough for both formats. Otherwise, enable passthrough
> for only the format your equipment supports."

That's good, yeah.

>>> +<para>
>>> +Although it is not possible to exactly imitate a surround system,
>>> +<application>MPlayer</application>'s HRTF filter does provide more spatially
>>> +immersing audio in 2-channel headphones. Regular downmixing simply combines all
>> 
>> I'd probably recommend "immersive" here instead.
> 
> Now, this is funny: that's exactly what I had there until ispell told
> me "immersive" isn't a word. Merriam Webster says it isn't either.
> Dictionary.com and the Oxford English Dictionary say it is. I'll
> change it back.

Heh. Weirdly enough, the collection of dictionaries offered by my local
dictd also doesn't recognize it - but I've been familiar with the word
for as long as I can remember, and there are times when I trust myself
over any other resource.

This isn't the first time I've trumped a digital database on something
linguistic, but usually it's been a matter of *spelling*, not a word's
existing in the first place. ^_^

>>> +<para>
>>> +The <option>-channels</option> option is used to request the number of
>>> +channels from the audio decoder. Some audio codecs (such as liba52 for decoding
>>> +AC3) use the number of specified channels to decide if downmixing the source is
>>> +necessary. Note that this does not always affect the number of output channels.
>>> +For example, using <option>-channels 4</option> to play a stereo mp3 file will
>>> +still result in 2-channel output since the mp3 codec will not produce the extra
>>> +channels.
>> 
>> Is it necessary to note what liba52 is used for, here? It seems a
>> little off - if nothing else, it seems to imply that it might be
>> the case that liba52 does this *only* when decoding AC3, not when
>> doing something else. Whatever the problem is, it can probably be
>> avoided by saying something like "such as liba52, used for decoding
>> AC3".
> 
> I mention liba52 because it's the most important example, but since I
> wouldn't expect most users to relate that to AC3 I wanted to say
> what liba52 does. Now that I think about it, though, most users
> probably won't know that AC3 is used for DVDs either. I suppose it is
> sufficient that I have examples showing how to use -channels with
> DVDs. I'll remove the parenthetical statement.

To accomplish the purpose you intended, a comment in that location - 
either parenthetical or set out by commas - to the effect of "including
some commonly used for DVDs" (or "including the one used for DVDs" if
AC3 is the only valid DVD audio codec) might not be bad.

>>> +<para>
>>> +This averages both channels, resulting in both channels being half as loud as
>>> +the original. The next sections have examples of other ways to do this without a
>>> +volume decrease, but they are more complex and require different options
>>> +depending on which channel to keep. If you really need to maintain the volume
>>> +than an easier way is to experiment with the <option>volume</option> filter and
>>> +find the right value. For example:

>> "than" (in that last full sentence) - you mean "then". I'd actually
>> recommend replacing the word with a comma, for better sentence
>> flow. (That might introduce problems of its own, around "way", but
>> even if so I think they're more ignorable.)
> 
> That's a typo. I don't have any preference for "then" instead of a
> comma. To what problems do you refer?

...I didn't enumerate it before because I wasn't sure I could do so
comprehensibly (see comment just below), but I'll give it a try. I think
it has to do with the fact that there is no appropriate verb on the
right-hand side of the place where the comma would go - saying "an
easier way to do so" would fix that problem, but would flow considerably
less well, making the sentence worse overall.

(One thing to understand is that most of the things I point out don't
arise from me taking a list of grammatical rules and going through
whatever document is at hand looking for violations. Instead, I read
through the document until my internal parser sticks its head up and
says "hey, that isn't right", and then I try to figure out why not, and
then I try to explain that, and then I try to come up with a solution. I
don't always succeed at any, much less all, of those last three steps.)

>>> +<listitem><para>
>>> +There should be two output channels: one for each speaker. The first suboption
>>> +is "2".
>> 
>> I'd probably prefer a comma rather than a colon, in the above
>> sentence. If you do want more of a break than that, you could use a
>> hyphen (" - ") or emdash instead; I think my objection is mainly on
>> the basis of your having made so much use of the colon for marking
>> off lists elsewhere in this document.
> 
> I think using a colon here is actually correct, but I'm having a hard
> time finding proof. I think my usage falls under the category of
> this quote from a Wikipedia article:
> 
> "The colon is used when the following clause is expanatory[sic] of
> the one already expressed, or additional, without an introductory
> conjunction. It is used to precede a clause which is the result of
> the preceding clause."
> 
> http://en.wikipedia.org/wiki/Colon_(punctuation)
> 
> If you feel strongly about this we'll talk more.

I admit that I don't much like the usage referenced in that quote, but
yes, I think it is considered valid. I believe that the alternate forms
I suggested would also be correct, or at least not incorrect, and would
avoid collision with the fact that the colon is used so many times
elsewhere in the document with a completely different function - which I
think is the main thing that tripped me up here.

(Not the only thing, mind you; as I already said, I apparently don't
much like the usage in the first place. But it is the primary
justification for changing the thing, other than "I don't think it feels
right".)

>>> +<bridgehead>Example: downmixing a 6-channel wave file</bridgehead>
>>
>> Technically, to the best of my knowledge, there's no such thing as
>> a "wave file". It's either a "WAV file" (capitalization may vary
>> AFAIK, although this is my own preferred form) or a "PCM file".
>> 
>> The same usage occurs below, in at least one other place.
> 
> I changed them to "PCM" (but not "PCM file", since, I think,
> WAV/WAVE/Wave is the container and PCM is the codec.

That's true, but AFAIR sometimes at least there is no container, and in
those cases the file is called simply a "PCM file".

>>> +The first set of suboptions lists the percentages, in order, that each channel
>>> +listed above should be mixed into the front left channel: "1:0:1:0:0.5:1". For
>>> +the front right channel: "0:1:0:1:0.5:1".
>> 
>> "percentages, in order, of each channel listed above that should be
> 
> Hmm.
> 
> "...the percentages of the original volume, in order, at which each
> channel listed above..."

Even better.

>> mixed", et cetera. You could also use "which" instead of "that",
>> but I've been given to understand (albeit by a
>> not-necessarily-authoritative source) that "which" in such a sense
>> is strictly appropriate only when following a comma.
> 
> I don't know for sure, and I'm too tired of grammar by now to think
> about it. Of course, "at which" is a rather different usage.

Indeed so.

>>> +</sect3>
>>> +
>>> +</sect2>
>>> +
>>> +</sect1>
>> 
>> I don't know XML very well, but it would seem intuitive to me that
>> each of these should have been closed immediately before the
>> following section began... meaning that only section 3 should
>> remain open, here.
> 
> The sections are hierarchical. A sect1 can include sect2s, a sect2
> can include sect3s, etc.

Okay - it still doesn't seem especially intuitive (although also not
especially counterintuitive), but if you say so, I'll take your word for
it.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.