RAR set compleet, toch CRC fout

[Verwijderd]

Besten,

Ik heb een set RARs gedownload (.r01, r02, etc.) die volgens MultiPar als ook volgens de ingebouwde par2cmdline van NewsLeecher volledig compleet is. Na het verifiëren zeggen beide programma's dat alle RARs compleet en in orde zijn, al krijg ik bij het testen via WinRAR of het uitpakken zelf steeds bij een aantal dezelfde RARs een CRC fout. Uiteindelijk kan hij de ingepakte bestanden niet uitpakken.

Heeft iemand een idee wat dit is en hoe ik het kan fixen? Ik kan de ingepakte bestanden helaas niet van een andere bron krijgen, al betwijfel ik of de bron het probleem is gezien onderstaande feiten.

- Verificatie via MultiPar en par2cmdline succevol, geen fouten.
- Bestandsgrootte tot op de byte af compleet.
- De RARs waar het probleem optreedt al meermaals gedownload maar zonder succes.
- Ook geprobeerd de 'foutieve' RARs volledig te verwijderen en nieuwe RARs door de PARs te laten maken.

Eigen conclusie dus ver: RARs zijn niet corrupt zoals wel eens voorkomt bij incomplete usenet bestanden of een mislukte downloadpoging, indien dit geval was zou MultiPar/par2cmdline een fout geven bij de verificatie.

[Verwijderd]

Dan is de rar door middel van Par al met CRC fouten in elkaar gezet. Hij keurt 'm dan als goed maar de CRC van oorsprong klopt al niet meer.

[Verwijderd]

Dat klinkt als een zeer zinnig argument. Stel dat dit het probleem is, is er dan een methode om dit op te lossen?

[Verwijderd]

Verwijderd schreef op dinsdag 06 maart 2012 @ 23:45:
Dat klinkt als een zeer zinnig argument. Stel dat dit het probleem is, is er dan een methode om dit op te lossen?

Je zou als redmiddel de Rar Repair functie nog kunnen doen. Maar dan pakt ie alleen de bestanden eruit die 'wel' nog leesbaar zijn.

Voor de rest ben je dan afhankelijk van wat er opnieuw wordt gepost zodat je dit kunt downloaden. Succes!

[Tsurany]

Lijkt mij dat de RAR idd defect was voor de parity controle plaatsvond. Dan 'repair' je hem naar de defecte staat. Niks aan te doen dan.

[CyBeR]

Inderdaad. Die PARs zijn redelijk fool-proof (dat zit best ok in elkaar), maar als de originele RAR al fucked was kan PAR ook niks.

De meeste unarchivers kunnen de file extracten en de CRC negeren. Afhankelijk van het soort file en het soort fout kan dat nog gewoon werken. Een filmpje werkt bijvoorbeeld meestal wel, alleen krijg je op een gegeven moment even tijdelijk een corrupt beeld.

[J2pc]

Tsurany schreef op woensdag 07 maart 2012 @ 00:07:
Lijkt mij dat de RAR idd defect was voor de parity controle plaatsvond. Dan 'repair' je hem naar de defecte staat. Niks aan te doen dan.

FF heel stom, maar ik heb 'vreemde' problemen gezien met rar files, installers etc. als je ze in een virtual machine probeert uit te pakken, terwijl ze nog op een schijf op het host OS staan. Oplossing was om de files eerst ín de VM te kopieren en dan pas uit te pakken.

Als je geen flauw idee hebt waarover dit gaat, is het waarschijnlijk niet van toepassing

[Verwijderd]

Wil je rar files maken die al bij voorbaat corrupt zijn dan moet je PC niet 100% meer werken. Geheugenfouten en dat soort dingen veroorzaken voornamelijk CRC fouten met het aanmaken van rar bestanden. Het gaat dan weer net goed met het maken van Par bestanden, maar daar is dan ook alles mee gezegd

[jan99999]

Dit komt vaak voor.
Bij een film kan ik deze vaak uitpakken, en bij afspelen werken ze gewoon, dus geen avi rapair bijvoorbeeld.
Ik zou bij een film alleen goed kijken of er geen stuk van de film weg is, dus steeds een stukje naar voren springen en kijk of je geen storing krijgt tijdens afspelen.

[Verwijderd]

Nee, ik ben niet bezig met VMs dus dat zal het probleem niet zijn.

Verder is het een image file van een DVD dus het is geen kwestie van een paar missende of corrupte frames in een MKV...

[wagenveld]

Kan ook zijn dat je geheugen problemen hebt op je PC, voor de zekerheid even een memtest draaien?

[Verwijderd]

Lijkt me heel sterk maar zal het doen. Heb al grotere RAR sets uitgepakt die dus meer geheugen nodig hebben.

[Verwijderd]

Nope.. Niks mis met m'n RAM.