README's second sentence lends itself to misinterpretation #7
Comments
|
That is not the only problem with that sentence: 705,600,000 is actually the only number smaller than a billion that is an integer multiple of one thousand times those frame rates along with 44100 and 192000. The smallest time unit which is LARGER than a nanosecond and also an integer fraction of 1000 times the frame rates 24, 25, 30, 48, 50, 60, 90, 100 and 120 Hz is 1/997,200,000 sec. The audio sample rates must be included to yield the chosen value. |
|
That initial description confused me too. Maybe just leave out that bit (which isn't actually useful) and say that it is a time unit which works really well to represent the period of all the common sample rates integrally. (or something along those lines). |
|
Language lawyers, all of ye! I'll try to tighten it up. |
|
Okay, fixed it by creating a run-on sentence. I'll happily consider pull-requests with elegant wordsmithing fixes, to a reasonable degree. |
|
LGTM, but please change "NTSC approximate frame durations" to "NTSC frame durations". There's nothing approximate about them (Flicks can represent them exactly). |
|
The approximation is that, as it has been explained to me, the "frame
duration" in NTSC is technically oscillating between two amounts, and not a
fixed value, and is only fixed precisely every 1001 seconds. I'll admit
that the precise understanding of NTSC's interleaved field periods is well
outside my area of expertise. Any time I've personally had to work with
NTSC in production (many years ago), we just used 29.97 and went on with
things.
…On Wed, Jan 24, 2018 at 3:20 PM, Dithermaster ***@***.***> wrote:
LGTM, but please change "NTSC approximate frame durations" to "NTSC frame
durations". There's nothing approximate about them (Flicks can represent
them exactly).
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABBQP3-vsscFYGSLWfg-f5i2ZDvn834ks5tN7rSgaJpZM4RpF1P>
.
|
|
In any case, I removed the word approximate. Huzzah!
On Wed, Jan 24, 2018 at 3:26 PM, Christopher Horvath <blackencino@gmail.com>
wrote:
… The approximation is that, as it has been explained to me, the "frame
duration" in NTSC is technically oscillating between two amounts, and not a
fixed value, and is only fixed precisely every 1001 seconds. I'll admit
that the precise understanding of NTSC's interleaved field periods is well
outside my area of expertise. Any time I've personally had to work with
NTSC in production (many years ago), we just used 29.97 and went on with
things.
On Wed, Jan 24, 2018 at 3:20 PM, Dithermaster ***@***.***>
wrote:
> LGTM, but please change "NTSC approximate frame durations" to "NTSC frame
> durations". There's nothing approximate about them (Flicks can represent
> them exactly).
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
> <#7 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AABBQP3-vsscFYGSLWfg-f5i2ZDvn834ks5tN7rSgaJpZM4RpF1P>
> .
>
|
|
Thanks! I've been working with 29.97 for years and read Poynton's books a couple times and I don't know what you mean (but maybe I'll learn something new today?). Even if there was such a thing with analog NTSC, the digital representation is a fixed period of 1001/30000 second for every frame with no oscillation. Maybe you're thinking of dropframe timecode, which is a whole other ugly (but related) can of worms. |
|
I'm happy to leave it where it's at now, I really appreciate the feedback.
I might go in and just remove the parts I'm waving my hands about, the
variable time rate.
…On Wed, Jan 24, 2018 at 4:12 PM, Dithermaster ***@***.***> wrote:
Thanks! I've been working with 29.97 for years and read Poynton's books a
couple times and I don't know what you mean (but maybe I'll learn something
new today?). Even if there was such a thing with analog NTSC, the digital
representation is a fixed period of 1001/30000 second for every frame with
no oscillation. Maybe you're thinking of dropframe timecode, which is a
whole other ugly (but related) can of worms.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABBQMDh26IsUN_EIY4zs8lTkA0k4ohSks5tN8bbgaJpZM4RpF1P>
.
|
Slashdot and The Verge both used "the smallest time unit which is LARGER than a nanosecond" alone to describe Flicks, to widespread confusion. Coverage is always weird, but I think the second sentence of the README isn't helping.
Specifically, the comma after "the smallest time unit which is LARGER than a nanosecond" suggests everything that follows is inessential description. That is, commas after a noun phrase often precede additional description that can safely be dropped without making the sentence false. Grammar references have good samples of the comma/no-comma rule for essential/inessential descriptions.
I think the comma was used there because the clauses are long and it felt like there needed to be some separation there, but given the usual rule folks see it as indicating that "the smallest unit larger than a nanosecond" is a sufficient standalone description and what follows is just additional detail, which of course isn't the case. You look at it and say "obviously the first part can't stand alone since there can be arbitrarily many units smaller than a Flick but larger than a nanosecond," but some folks just parse the text literally.
If you don't feel like simply removing the comma, you could use some construct like "which 1) is larger than a nanosecond and 2) evenly divides...": that would set off the clauses clearly without the confusing comma, and the emphasis on the 'and' might further keep folks from confusing themselves.
The text was updated successfully, but these errors were encountered: