Użytkownik "HF5BS" napisał w wiadomości grup
dyskusyjnych:oougb0$2f6$...@n...news.atman.pl...
Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
>>>Więcej, to jest w stanie odtworzyć nawet kilka utraconych plików,
>>>jeśli tylko ilość straconych danych nie przekracza możliwości
>>>naprawczych.
>
>> Bo sie rozrzuca zestawy danych. W efekcie nie mam straconych 1000
>> bitow ciurkiem, tylko np po jednym bicie w 1000 blokow, kazdy
>> objety osobnym RSC.

>Z szybkiego policzenia wyszło mi, że to prawie 13.5 sekundy treści,
>chciało(by) im się aż tyle?

Chodzilo mi o to, ze tak szacujac z pamieci - pit na plycie ma ~1um,
co nam daje z zgrubsza 1000 bitow/mm sciezki, sektor ma cos 23xx
bajtow, czyli ponad 18kb i trwa 1/75s, i wychodzi ze z grubsza 18mm
zajmuje.

ten 1mm utraty danych naped odtwarza, wiec zrobillbym to np tak, ze
jednym 19-bitowym blokiem kodu korekcyjnego sa objete bity nr 1, 1001,
2001 ... 18001.
Drugim blokiem bity nr 2, 1002, 2002, ... 18002 itd.
I juz nam 1mm plama nie straszna.

Moze nawet wiekszy sens mialoby rozlozyc to miedzy sektorami, czyli np
bity nr 1 z 19 sektorow, kolejny na bity nr 2 itd, ale ... to by chyba
wymagalo pamieci na tych 19 sektorow przy odtwarzaniu, i juz pierwsze
odtwarzacze maja problem, bo te kilobajty byly w tym czasie drogie.

A potem z tych 23xx bajtow audio zrobiono 2048 bajtow danych, gdzie
mozliwosci odtworzenia musialy byc jeszcze duzo wieksze, bo komputer
nie zniesie ani jednego przeklamanego bitu.

>> A potem przyjdzie fajny naped i przestawi ustawi co 8-my bit :-)
>Hmm... Jeśli to by miało zadziałać ku polepszeniu, to choćby
>krasnoludki i Królewna Śnieżka... Ale, jeśli źle FW napiszą, to
>różnych rzeczy się spodziewać można.

Ale sam wiesz, ze to sie zdarza, a wtedy taki pomysl "blokiem kodu
obejme co 1024 bit" przestanie dzialac :-)

J.