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

[Corey Hickey]

The Wanderer wrote:
> I don't see a new patch, actually.

Yep; I forgot. It doesn't really matter, I addressed almost all your
points in the body anyway.

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

I forgot. Interestingly enough, I never noticed when the softvol options
were added to MPlayer. I was considering writing a quick volume
adjustment guide...

...and I've done so now. Let's see if I remember to attach the patch
this time.

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

I operate that way too, except that when a sentence makes sense to me
and is formally correct I don't feel like changing it; however, I
understand what you wrote about pausing and sentence flow, and, although
I still consider the sentence acceptable, I'll add a subject to the
second clause and a comma before "but".

"MPlayer supports surround playback, but this feature is not enabled by
default because stereo equipment is by far more common."

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

This stuff is fun but it wearies me. I'm glad to see you putting the
effort into scrutinizing docs patches; being the resident grammarian is
a difficult job, especially without formal training, and I never had the
gumption to step forward and take on the task myself.

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

I used to pronounce each letter, until a musician friend of mine (who
does all his recording, mixing, and editing on the computer) said
"spidiff" to me. The other person I've heard pronounce it was an
audiophile. That's all I have to go on, so I'll just leave it as it is.

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

Wow, I never knew dictd existed. Interesting...

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

Looking at this with a fresh brain this morning gave me an easy fix:
"If you really need to maintain the volume, it may be easier to
experiment..."

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

I understand. That's the way I work too.

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

Ironically, I used a colon there in the first place so that I could
easily avoid the two sentence structures I'd been using for that purpose:
"Since ... ... , ... ..."
"... ... , so ... ..."

Here's something entirely different:
"In order to provide an output channel for each of the two speakers, the
first suboption must be "2"."

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

They end up corresponding to the hierarchy in the table of contents:

3.6. Advanced Audio
    3.6.1. Surround/Multichannel Playback
        3.6.1.1. DVDs
        3.6.1.2. Playing Stereo Files to Four Speakers
        3.6.1.3. AC3/DTS Passthrough
        3.6.1.4. Matrix-encoded Audio
        3.6.1.5. Surround Emulation in Headphones
        3.6.1.6. Troubleshooting
    3.6.2. Channel Manipulation
        3.6.2.1. General Information
        3.6.2.2. Playing mono in two speakers
        3.6.2.3. Channel Copying/Moving
        3.6.2.4. Channel Mixing


3.6 is sect1.
3.6.x are sect2s.
3.6.x.y are sect3s.

(3 itself is a chapter, not a sect)

-Corey
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: advaudio-2.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-docs/attachments/20050904/d8c36197/attachment.asc>