|
|
Posted by Martin Heffels on 10/05/71 11:53
On Tue, 11 Jul 2006 07:38:03 GMT, "PTravel" <ptravel@travelersvideo.com>
wrote:
>> You can answer that question based on your own experience of course. What
>> these numbers tell you is that there is a lot happenening that you don't
>> even notice, repaired unnoticeable to you, but noticeable to the player.
>
>And what the numbers don't tell me are how many of them are uncorrectable.
>Is sticking to the subject really that difficult?
Did you miss out that I said "You can answer that question based on your
own experience"?
>> Think about it: 100 drop-outs per minute. They won't all be correcteable,
>
>How do you know? That's a rhetorical question, by the way. The answer is,
>you don't and the Sony sheet that you posted doesn't provide the answer.
That's right. But I keep looking for more info.
>
>> so repair will take place by copying/interpolating data. Seeing the amoun,
>> I really start to believe that every copy you make, you loose data and
>> thus
>> you loose a generation.
>
>You believe a lot of things. I'm not interested in your beliefs. I'm
>interested facts. So far, you've presented none.
I presented you with the fact that there are already a lot of errors when
you playback your tape. I bet you didn't even realised that, and that is
all because you didn't see it. On the DSR1800-deck I have seen the meter
frequently drop into the red bar, but the picture still looked ok. That
means that the error-correction is doing a bloody good job in correcting
the errors somehow.
>No need. Once more: D-25 video has better quality than DVD-compliant mpeg.
>Period.
Not at the same bitrate. That's what I said. Proved in yet another
SMPTE-article. And I think I also posted a link to a codec-quality
comparison which tells the same.
>> Many more articles written about this with the arrival of HDV which tells
>> you I am right.
>
>Irrelevant to the discussion. We're not talking about HDV, but the
>comparison between D-25 and mpeg2.
And, what compression does HDV use again? :-) HDV has a higher pixel-count
than DV25, yet it is compressed to MPEG2 with the same bitrate as DV25, and
still looks better. Tells me that MPEG2 is a much more efficient way of
compressing video than what is used with DV25.
>Typical non-lawyer misunderstanding of what that means, which is this: the
>state bears the burden of proving, beyond a reasonable doubt, the existence
>of facts that compel a finding of guilt. You and Richard keep insisting
>that that D-25 results in generational loss because of the existence of
>uncorrectable errors.
I will make it even worse for you: even with corrected errors you get
generation loss. Because the errors can be corrected so _you_ don't see
them, but the bits are different from what they originally where, so you
have lost a generation.
>I've asked you to quantify the number of
>uncorrectable errors, since a miniscule amount is meaningless for the
>purpose of this discussion, which is: will D-25 result in more generational
>loss than SuperBeta?
It had to do with component vs firewire copy to begin with. Then generation
loss popped up, in which DV25 and Beta-SP where mentioned, and now the
severeness of the error-correction.
>You haven't met your burden of proof because (1) you've provided no evidence
>but, more importantly, (2) you don't know.
I do know, but I am looking for more facts. That's what you would do in
your profession as well.
>Entirely predicated upon speculation, with no foundation in fact. All
>right, here's some more speculation. I'll take Richard's 8 bits per 10
>minute error guestimate, resulting in a reliability for D-25 of 99.99999975%
>
>So, 100 errors per minute * 30 minutes = 3000 errors, .00000025% of which
>are uncorrectable and result in data loss. That's a total of 0.00075 errors
>per 30 minutes, or 0.0015 errors per hour of video. Put another way, you'd
>have to shoot 666 hours of video before you hit one uncorrectable error.
666 hours? Eeek :-) But let me bring this forward again and again: errors
can be corrected without you noticing it, by borrowing or interpolating,
but they content of the bits has changed.
>Using Richard's assumption, as well as yours.
>
>Now, me -- I don't like to assume. I like hard data.
>
>Let me know if you get some.
Only if you promise to read them :-)
[...]
>I missed the link, though, as it turns out, it wasn't relevant to anything
>in this discussion.
No, it wasn't. It's probably not what you wanted to hear.
>> So whatever I find, I will keep for myself, and maybe
>> share it with mr Crowley, and Craig the Tapeguy, and let you live in your
>> perfect world, so you don't have to worry too much. It might distract you
>> from shooting your nice city-footage ;-)
>
>Yes, feel free to be the Guardian of Secrets. That's not why you post on
>Usenet anyway, is it?
I am a Knight of The Templars and guard even bigger secrets. But don't tell
anyone.
>
>
>>
>>>That means that 99.99999975% of the time, the data is accurate, i.e. a
>>>bit-for-bit copy.
>>
>> That is not a bit-for-bit copy, because that would be 100%!
>
>I'll tell you one thing that it's not, though: "generational loss."
It _is_ generational loss, because you have something which is different
from the original. Just like an analogue video has more noise and
chroma-errors once it has been copied, which means it is different from the
original caused by copying.
cheers
-martin-
--
"If he can he'll smile 'cos he's a Royal Crocodile."
Navigation:
[Reply to this message]
|