[MPlayer-DOCS] CVS: main/DOCS/xml/en encoding-guide.xml,1.8,1.9

The Wanderer inverseparadox at comcast.net
Mon Aug 15 21:33:26 CEST 2005


(Gack. I thought I'd mailed this out hours ago! Here it is anyway...)

Guillaume POIRIER wrote:

> Hi,
> 
> On 8/15/05, The Wanderer <inverseparadox at comcast.net> wrote:
> 
>> Guillaume Poirier CVS wrote:
>> 
>>> +  Experience shows that NTSC contents are a lot more difficult to encode
>>> +  given that there more elements to identify in the source.
>> 
>> This says that in the case that there are more elements to identify
>> in the source, NTSC contents are a lot more difficult to encode. Is
>> that what you meant?
>> 
>> (I'm going to be correcting at least one other thing - the missing
>> comma, and perhaps "material is" instead of "contents are" -
>> anyway, but if the above isn't what you meant I can rephrase it a
>> bit at the same time.)
> 
> I really struggled here to make a good sentence here, and I'm not
> surprised that it doesn't suit you as it doesn't suit me as well.
> 
> What I'm trying to say here is that on NTSC content, more elements
> have to be identified on the source. If you don't make make that
> preliminary work, your encode is guaranteed to either fail or look
> terrible.
> 
> With PAL content, you just have one element to take into account:
> interlacing, which won't make your encode fail it you don't take it
> into account, it'll just look bad.

That's what I thought (although I didn't know the technical details). I
had a fix ("because" instead of "given that") in mind from the
beginning, and it looks like it was correct; fixed locally.

>>>    Besides being ugly, the artifacts also harm coding efficiency:
>>>    You will get worse quality per bitrate.
>> 
>> I don't know if I've mentioned it before - I think I must have,
>> since I know I've seen this line - but I don't like the phrasing
>> "per bitrate". The simplest fix would be to say "per unit bitrate"
>> instead, but that's a more formal type of language not necessarily
>> well suited to something whose tone is not explicitly technical;
>> I'd prefer something else if such a thing can be found.
> 
> If I were to use "unit" here, I'd write smth such as: "You will get
> worse quality per bitrate unit", which sounds better to me. :)

It doesn't to me, however; I don't think I've ever come across that
phrasing before, even in "bad" English much less in "good" English. The
phrasing "foo per unit bar" is very standard IME, it's just more formal
than may be warranted.

A slightly less objectionable alternate phrasing, from my end, would be
"per unit of bitrate", but that also has problems although I don't
currently know how to fix them any more than I know how to fix the main
problems of the previously suggested fix.

I'll hold off on committing the rest until this is addressed, or until
this evening if I don't get any replies by then.

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




More information about the MPlayer-DOCS mailing list