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

[The Wanderer]

Corey Hickey wrote:

> The Wanderer wrote:

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

Yep, it came through. There are a few things I have comments on, in the
new section, but those can be addressed retroactively.

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

That works very well.

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

Oh, believe me, I know *exactly* how that feels.

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

I sort of slipped into it sideways, almost by accident; I let about as
many things go by untouched as I actually comment on, but I do try to
handle my share of the part of the work I can actually do.

>> [S/PDIF]

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

Yeah, dict and its collection of available dictionaries are one of my
most often used utilities. One dictionary module you may want to
install, which you might not notice immediately, is VERA - the Virtual
Entity of Relevant Acronyms; it's been very useful on a number of occasions.

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

Not entirely ideal, but that's a definite improvement.

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

That does serve the purpose, but breaks parallelity (now *that* might
not be a word) with the fact that you've had the implied form (which I
like) "Therefore, the Nth suboption is #." in all other instances.

The only phrasings I can think of offhand which both avoid the colon
issue and retain that form keep coming out very much like your original
version, except with different punctuation... it might be better to just
leave things as they were committed, i.e. with the new form above.

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

<snip>

> 3.6 is sect1.
> 3.6.x are sect2s.
> 3.6.x.y are sect3s.
> 
> (3 itself is a chapter, not a sect)

That makes sense. Thank you.

> +<sect2 id="advaudio-volume">
> +<title>Software Volume Adjustment</title>
> +
> +<para>
> +Some audio tracks are too quiet to be heard comfortably without amplification.
> +This becomes a problem when your audio equipment cannot amplify the signal for
> +you. The <option>-softvol</option> option directs
> +<application>MPlayer</application> to use an internal mixer. You can then use
> +the volume adjustment keys (by default <keycap>9</keycap> and
> +<keycap>0</keycap>) to reach much higher volume levels. Note that this does not
> +bypass your sound card's mixer; <application>MPlayer</application> only
> +amplifies the signal before sending it to your sound card.

Um... on my system, I adjust the volume using the / and * keys (on the
number pad), and to the best of my awareness I've never modified the
input configuration from its default; I've just checked the man page in
mid-paragraph and found that 9 and 0 are also listed, but it might -
repeat, *might* - be a good idea to say something like "by default 9 or
/ and 0 or *".

> +
> +The following example is a good start:
> +
> +<screen>mplayer <replaceable>quiet-file</replaceable> -softvol -softvol-max 300</screen>
> +
> +The <option>-softvol-max</option> option specifies the maximum percentage of the
> +original volume. For example, <option>-softvol-max 200</option> would allow the
> +file to be played up to twice as loud.

This is a difficult concept to explain properly, especially while
attempting to maintain good English; I understand what is meant, from
the description in the first sentence above, but I'm not sure I would
have if I didn't already know.

How about "specifies the maximum allowable volume as a percentage of the
original volume"? I think that manages to be more comprehensible while
avoiding the problems I've usually encountered trying to explain it.

I might choose to say "would allow the volume to be adjusted up to twice
its original level", but that may be more technically phrased than you
want to go with here.

> It is safe to specify a large value with
> +<option>-softvol-max</option>; the higher volume will not be used until you
> +use the volume adjustment keys. The only disadvantage of a large value is that,
> +since <application>MPlayer</application> adjusts volume by percentage of the
> +maximum, you will not have as precise control when using the volume adjustment
> +keys.

It might be worth making note, here, of the -volstep option (which I
personally didn't realize existed before yesterday) - it allows you to
choose exactly *what* percentage of the maximum will be used for the
adjustment increment. It isn't possible to increase the available
precision very much by that option, since its default is only 3 (minimum
0, minimum practical 1) and it appears to take only an integer argument,
but some people still might find it useful.

> +This will play the file with a ten decibel gain. Be careful when using the
> +<option>volume</option> filter - you could easily hurt your ears if you use
> +too high a value. Start low and work your way up gradually until you get a feel
> +for how much adjustment is required. Also, if you specify excessively high
> +values <option>volume</option> may need to clip the signal to avoid sending your
> +sound card data that is outside the allowable range. You will hear distortion
> +when this happens.

I'm not particularly happy with the feel of that last sentence - it
seems a little off in some way I'm not sure of. How about inserting a
comma after "values" and saying "allowable range; this will result in
distortion" (or even "distorted audio")?

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