Nikon FX SLR (DF, D1-D5, D600-D850) Diskusjonsforum.

i dag provde jeg for forste gang backup-modusen pa min D810 for a sikre bildene.

CF Sandisk 16 GB Extreme PRO (160 MB / s)

SD Sandisk 32 GB Extreme PRO (95 MB / s)

Sa hvert skudd har blitt kopiert pa begge kortene (i rekkefolge desverre ikke parallelt, men det er en annen historie)

Jeg brukte deretter et sjekksumverktoy for a sammenligne filene for a sikre at begge kopiene var identiske, men sjekksummet mislyktes pa hver av de 450 bildene jeg tok.

Jeg lastet noen par i Photoshop og laget et forskjellslag .. ingen visuell forskjell.

Jeg brukte deretter en Hex-redaktor og til slutt fant ut at ved CF 007F5C ville CF-kortet ha «01» og SD «00».

Dette syntes a v re den eneste forskjellen i flere tvillingfiler.

Jeg skrev til Nikon og har et vagt hap om a fa svar (i tilfelle jeg postet det her), men onsket virkelig a fa noen synspunkt pa dette.

Har du hatt noe lignende problem?

min plan er a kjore sjekksummer pa CF og SD pa slutten av hver okt, hvis alt er justert, kan jeg kopiere og reformat CF (siden det er raskere) til et annet lagringsplass og beholde en storre SD-storrelse som sikkerhet- nett nar jeg reiser.

Kanskje noen forskjell i exif data mellom kopier?

Mitt gjetning er metadataene for a identifisere kortsporet.

& Quot; 00 & quot; for CF, «01» for SD (selv om dette valget er sannsynlig vilkarlig.)

Legg merke til at minnestedet er sv rt n r en adresse «grense 7FFF (h)

Ja, det var min tanke ogsa, men dette ville bekrefte at det ikke er mulig a sammenligne bit-by-bit de 2 kortene for a sikre at ingen korrupsjon oppstod.

Eventuelle losningen du kan tenke pa?

Tusen takk for tilbakemeldingene dine!

Mitt gjetning er metadataene for a identifisere kortsporet.

& Quot; 00 & quot; for CF, «01» for SD (selv om dette valget er sannsynlig vilkarlig.)

Legg merke til at minnestedet er sv rt n r en adressegrense 7FFF (h)

Det ville v rt min gjetning ogsa, noe som betyr at det ville v re denne metadataen i filen. & # 160; Bildedataene er identiske, sa for alle formal er det en eksakt kopi.

Gabriele Morano skrev:

Ja, det var min tanke ogsa, men dette ville bekrefte at det ikke er mulig a sammenligne bit-by-bit de 2 kortene for a sikre at ingen korrupsjon oppstod.

Eventuelle losningen du kan tenke pa?

Tusen takk for tilbakemeldingene dine!

Hvis dette er den eneste endringen, ma du skrive et enkelt C-program (eller et annet favoritt sprak) som apner filen, blar pa biten og flyttes til neste fil. Nar # # # # # # # # # # # # # # # # # # # # # # # # # ############################################### ipad

Pa slutten av dagen nar korrupsjon far ppl til a rive pa haret, har skaden som er forarsaket, forarsaket at hele filen blir soppel, slik at du raskt kan sammenligne visuelt i stedet for a ha en enkelt piksel som burde v rt en 0xFFFF FFFF FFFF som en 0xFFFF FFEF FFFF i stedet.

IMO redundansen i kameraet er a beskytte deg mot eksponeringstidspunktet til den tiden du kan fa filen / filene til pa en datamaskin der du gjor dine ekstra sikkerhetskopier og arkiver.

Gabriele Morano skrev:

Ja, det var min tanke ogsa, men dette ville bekrefte at det ikke er mulig a sammenligne bit-by-bit de 2 kortene for a sikre at ingen korrupsjon oppstod.

Eventuelle losningen du kan tenke pa?

Tusen takk for tilbakemeldingene dine!

Hvis dette er den eneste endringen, ma du skrive et enkelt C-program (eller et annet favoritt sprak) som apner filen, blar pa biten og flyttes til neste fil. Nar filmassering er ferdig pa katalogen, kan du gjore sammenligningsfil for fil – prob ma ogsa endre skrivedato til originalen.

Pa slutten av dagen nar korrupsjon far ppl til a rive pa haret, har skaden som er forarsaket, forarsaket at hele filen blir soppel, slik at du raskt kan sammenligne visuelt i stedet for a ha en enkelt piksel som burde v rt en 0xFFFF FFFF FFFF som en 0xFFFF FFEF FFFF i stedet.

IMO redundansen i kameraet er a beskytte deg mot eksponeringstidspunktet til den tiden du kan fa filen / filene til pa en datamaskin der du gjor dine ekstra sikkerhetskopier og arkiver.

Skal Xanth, jeg ventet pa den praktiske diy bit fiksering, men jeg er ikke fancy a komme inn i det enna, kanskje redundans paranoia vil bringe meg der en gang, men jeg prover a motsta!

Jeg er enig med deg i at jeg bare skal v re takknemlig for a fa skuddene trygge til slutten av dagen og deretter fortsette med sikkerhetskopier riktig, men det ville fortsatt ha v rt en sa slank prosess.

btw fortsatt ingen tilbakemelding fra Nikon til tross for 24 timers SLA, hvorfor er jeg ikke overrasket.

Gabriele Morano skrev:

min plan er a kjore sjekksummer pa CF og SD pa slutten av hver okt, hvis alt er justert, kan jeg kopiere og reformat CF (siden det er raskere) til et annet lagringsplass og beholde en storre SD-storrelse som sikkerhet- nett nar jeg reiser.

Jeg har to 128 GB kort og bruker dem i backup modus som vil holde mer enn 3500 bilder (24 MP). Det er en veldig anstendig tur uten (to) billedtanker. I en klemme kunne jeg kaste sikkerhet overbord og formatere backup-kortet for a fa ytterligere 3,500 + skudd.

Problemet med tiln rmingen din synes a v re at SD-kortet ser bra ut etter skytingen, men kan bli skadet senere.

Gabriele Morano skrev:

Ja, det var min tanke ogsa, men dette ville bekrefte at det ikke er mulig a sammenligne bit-by-bit de 2 kortene for a sikre at ingen korrupsjon oppstod.

Eventuelle losningen du kan tenke pa?

Tusen takk for tilbakemeldingene dine!

En ting du kan prove er en av de freeware-typen programmer som kan slette (fjerne) metadataene fra en fil. & # 160; Hvis du kjorte det pa begge filene, kan du bli heldig. (?)

Mitt gjetning er metadataene for a identifisere kortsporet.

& Quot; 00 & quot; for CF, «01» for SD (selv om dette valget er sannsynlig vilkarlig.)

Legg merke til at minnestedet er sv rt n r en adressegrense 7FFF (h)

Dette ville v rt min gjetning ogsa. Nar du overforer filer med Nikon Transfer, ma du velge et spornummer. Hvis du ikke velger riktig spor, vil filer ikke engang komme opp.