[MPlayer-DOCS] CVS: main/DOCS/xml/en mencoder.xml,1.62,1.63

[The Wanderer]

Diego Biurrun wrote:

> On Sat, May 14, 2005 at 12:45:54AM -0400, The Wanderer wrote:
> 
>>Guillaume Poirier CVS wrote:

>>> +  Television was designed to refresh these in alternation as a
>>> +  cheap form of analog compression.
>>> +  The human eye supposedly compensates for this, but once you
>>> +  understand interlacing you will learn to see it on TV too and
>>> +  never enjoy TV again.
>> 
>> I'd say "as much" before "again" here.
> 
> While I would normally agree here, this completely distorts what Rich
> is saying, he'd never make such a balanced and non-controversial
> statement, so I'll reject this change ;-)

I'd have no objection to this if the text in question were clearly
ascribed to Richard; as things stand, unless I've missed something there
is no indication of where the text came from much less exactly who's
responsible for any given portion of it. As such, unless you want to
attribute this directly to him in the text itself, I still think it
should be changed.

Be glad I'm not objecting to the assertion itself... I think it's
entirely possible that someone who does know the difference, and prefers
the look of video which is done the "right" way, could in fact still
enjoy "TV" in general just as much as before; they'd almost certainly
enjoy the non-TV things more, but that's a relative issue. ^_^

>> Also: elsewhere you have usages like "24fps", but here you have "25
>> fps". Presumably this is because it would be awkward to say "24
>> and 30fps", and at least nearly equally so to say "24fps and
>> 30fps"; still, it might be worth trying to keep things consistent.
> 
> I've wondered myself what the best way to solve this would be.

In this particular instance, it occurs to me that we may be able to
dodge the problem by simply expanding the acronym; "24 and 30 frames per
second" followed by either "25 frames per second" or "25fps" doesn't
look too bad to me, and it seems to fit the rule well enough.

>> See above re "fieldrate" (although it might be more awkward, here
>> and elsewhere, to have "field rate" and "framerate" - and I don't
>> think I'd like to propose separating the latter);
> 
> Since the spelling of framerate is fixed already, I'd be tempted to
> go with fieldrate to match it, even though I admit it looks a tad
> awkward.

Yes, I was primarily commenting on just that first usage; the only
reason I mentioned it again here was for consistency's sake, and of
course it seems like it would cause more problems than it solves.

>>> +  NTSC/PAL conversion is highly destructive and cannot be reversed
>>> +  cleanly, so your encode will greatly suffer if it is made from a
>>> +  converted source.
>> 
>> While I don't like the "NTSC/PAL" usage (specifically the "/"), I
>> admit that any other way of referring to conversion in both
>> directions which springs readily to mind is lengthier and probably
>> more awkward (or at least repetitive, as with "Conversion between
>> NTSC and PAL"); if you can come up with some better way of
>> expressing it I'd be happy, but it's probably best left as it is.
>> 
>> (Or... hmm. Would "Conversion between these two formats is highly
>> destructive" work?)
> 
> I think both "Conversion between NTSC and PAL" and "Conversion
> between these two formats is highly destructive" are better,
> Guillaume gets to choose.

I'd recommend the latter, because otherwise we have "Conversion between
NTSC and PAL" coming immediately after "converting between NTSC and
PAL", which as I said is repetitive; it's not fatal, but since we can
avoid it without harm, I think we should do so. If Guillaume chooses
otherwise, though, I won't object.

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