Bonjour,
J'ai voulu tester testdisk-6 trouvé sur 01net :
http://www.01net.com/telecharger/linux/Utilitaires/fiches/31186.html
Ça marche !
Ça marche même au-delà de mes espérances. J'ai soumis à la torture la
carte flash de mon APN (1 MO) après m'être amusé à la mettre en ext3
pour voir ce que disait mon appareil (error CF !) et qui me l'a
re-formatée en FAT vite fait. Testdisk m'a récupéré plus de 200 photos
dont certaines ont plus de 2 ans !
Ce logiciel est finalement bien indiscret. Comment me faudrait-il faire
si je voulais définitivement supprimer tout ce qui se trouve sur un
média sans aucun espoir de récupération ?
Merci et bonne soirée,
Dominique
Le Wed, 29 Aug 2007 11:30:22 +0200, Matthieu Moy a écrit:
Euh, là, je suis curieux de voir comment tu retrouves les 10 bits de départ à partir des 8 bits qu'il te reste ;-). Compression mise à part, il te faut toujours au final au moins la même quantité d'information que ce que tu veux récupérer.
Non non. Le code correcteur, c'est justement ça. Les 10 bits recodés en 15, avec la bonne méthode, tu peux perdre 7 bits sur les 15, les retrouver grâce aux 8 bits restants et maintenant que tu as reconstitué les 15 bits, tu calcules les 10 bits d'origine.
J'avais codé un algo de ce genre.
Le Wed, 29 Aug 2007 11:30:22 +0200, Matthieu Moy a écrit:
Euh, là, je suis curieux de voir comment tu retrouves les 10 bits de
départ à partir des 8 bits qu'il te reste ;-). Compression mise à
part, il te faut toujours au final au moins la même quantité
d'information que ce que tu veux récupérer.
Non non.
Le code correcteur, c'est justement ça.
Les 10 bits recodés en 15, avec la bonne méthode, tu peux perdre 7 bits
sur les 15, les retrouver grâce aux 8 bits restants et maintenant que tu as
reconstitué les 15 bits, tu calcules les 10 bits d'origine.
Le Wed, 29 Aug 2007 11:30:22 +0200, Matthieu Moy a écrit:
Euh, là, je suis curieux de voir comment tu retrouves les 10 bits de départ à partir des 8 bits qu'il te reste ;-). Compression mise à part, il te faut toujours au final au moins la même quantité d'information que ce que tu veux récupérer.
Non non. Le code correcteur, c'est justement ça. Les 10 bits recodés en 15, avec la bonne méthode, tu peux perdre 7 bits sur les 15, les retrouver grâce aux 8 bits restants et maintenant que tu as reconstitué les 15 bits, tu calcules les 10 bits d'origine.
J'avais codé un algo de ce genre.
Nicolas George
Arol wrote in message <46d54002$0$19455$:
Non non.
Ben si. Par pitié, arrête de parler de ce que tu ne connais pas.
Le code correcteur, c'est justement ça. Les 10 bits recodés en 15, avec la bonne méthode, tu peux perdre 7 bits sur les 15, les retrouver grâce aux 8 bits restants et maintenant que tu as reconstitué les 15 bits, tu calcules les 10 bits d'origine.
Non, c'est mathématiquement impossible. Si tu as 10 bits au départ, tu as 1024 combinaisons possibles. Si tu en perds 7 (et que tu sais les quels), il t'en reste 8, ce qui fait 256 combinaisons. Il y a donc plusieurs situations de départ qui te donnent la même situation d'arrivée, il n'est donc pas possible de reconstruire.
On n'en sort pas : il faut que l'information préservée à l'arrivée soit en plus grande quantité que celle de départ. Si tu as 10 bits au départ codés en 15, alors tu peux en perdre jusqu'à 5, mais pas plus.
Sauf qu'en pratique, on ne « perd » pas un bit, leur valeur se retrouve modifiée sans qu'on puisse le savoir. Dans ce cas, il faut plus de marge pour pouvoir reconstruire. Dans le cas de 10 bits, un calcul combinatoire simple indique qu'il faut au moins un code de 14 bits pour pouvoir corriger une erreur sur 1 bit, 18 pour 2 bits, 21 pour 3 bits. Un calcul plus fin serait peut-être encore plus pessimiste.
Arol wrote in message <46d54002$0$19455$426a34cc@news.free.fr>:
Non non.
Ben si. Par pitié, arrête de parler de ce que tu ne connais pas.
Le code correcteur, c'est justement ça.
Les 10 bits recodés en 15, avec la bonne méthode, tu peux perdre 7 bits
sur les 15, les retrouver grâce aux 8 bits restants et maintenant que tu as
reconstitué les 15 bits, tu calcules les 10 bits d'origine.
Non, c'est mathématiquement impossible. Si tu as 10 bits au départ, tu as
1024 combinaisons possibles. Si tu en perds 7 (et que tu sais les quels), il
t'en reste 8, ce qui fait 256 combinaisons. Il y a donc plusieurs situations
de départ qui te donnent la même situation d'arrivée, il n'est donc pas
possible de reconstruire.
On n'en sort pas : il faut que l'information préservée à l'arrivée soit en
plus grande quantité que celle de départ. Si tu as 10 bits au départ codés
en 15, alors tu peux en perdre jusqu'à 5, mais pas plus.
Sauf qu'en pratique, on ne « perd » pas un bit, leur valeur se retrouve
modifiée sans qu'on puisse le savoir. Dans ce cas, il faut plus de marge
pour pouvoir reconstruire. Dans le cas de 10 bits, un calcul combinatoire
simple indique qu'il faut au moins un code de 14 bits pour pouvoir corriger
une erreur sur 1 bit, 18 pour 2 bits, 21 pour 3 bits. Un calcul plus fin
serait peut-être encore plus pessimiste.
Ben si. Par pitié, arrête de parler de ce que tu ne connais pas.
Le code correcteur, c'est justement ça. Les 10 bits recodés en 15, avec la bonne méthode, tu peux perdre 7 bits sur les 15, les retrouver grâce aux 8 bits restants et maintenant que tu as reconstitué les 15 bits, tu calcules les 10 bits d'origine.
Non, c'est mathématiquement impossible. Si tu as 10 bits au départ, tu as 1024 combinaisons possibles. Si tu en perds 7 (et que tu sais les quels), il t'en reste 8, ce qui fait 256 combinaisons. Il y a donc plusieurs situations de départ qui te donnent la même situation d'arrivée, il n'est donc pas possible de reconstruire.
On n'en sort pas : il faut que l'information préservée à l'arrivée soit en plus grande quantité que celle de départ. Si tu as 10 bits au départ codés en 15, alors tu peux en perdre jusqu'à 5, mais pas plus.
Sauf qu'en pratique, on ne « perd » pas un bit, leur valeur se retrouve modifiée sans qu'on puisse le savoir. Dans ce cas, il faut plus de marge pour pouvoir reconstruire. Dans le cas de 10 bits, un calcul combinatoire simple indique qu'il faut au moins un code de 14 bits pour pouvoir corriger une erreur sur 1 bit, 18 pour 2 bits, 21 pour 3 bits. Un calcul plus fin serait peut-être encore plus pessimiste.
Arol
Le Wed, 29 Aug 2007 09:58:50 +0000, Nicolas George a écrit:
Non non.
Ben si. Par pitié, arrête de parler de ce que tu ne connais pas.
heu, j'ai retrouvé dans mes archives (1997). Type de code correcteur utilisé PGZ (reed solomon). 16 bits codés sur 31 bits GF(32) et j'avais droit à 3 bits d'erreurs. En codant sur 63 bits GF(64), j'avais droit à 9 bits d'erreurs.
Ce code la n'était pas le meilleur, il y avait celui à base d'euclide plus performant mais théoriquement plus complexe. Et si je me souviens bien, sur 15 bits, on pouvait bien avoir 7 bits d'erreur. Je dis 7 selon mes souvenirs, mais ça peut être 6 ou 5 pas moins en tout cas et ça m'a bien étonné à l'époque.
Le Wed, 29 Aug 2007 09:58:50 +0000, Nicolas George a écrit:
Non non.
Ben si. Par pitié, arrête de parler de ce que tu ne connais pas.
heu, j'ai retrouvé dans mes archives (1997).
Type de code correcteur utilisé PGZ (reed solomon).
16 bits codés sur 31 bits GF(32) et j'avais droit à 3 bits d'erreurs.
En codant sur 63 bits GF(64), j'avais droit à 9 bits d'erreurs.
Ce code la n'était pas le meilleur, il y avait celui à base d'euclide plus
performant mais théoriquement plus complexe.
Et si je me souviens bien, sur 15 bits, on pouvait bien avoir 7 bits
d'erreur.
Je dis 7 selon mes souvenirs, mais ça peut être 6 ou 5 pas moins en tout
cas et ça m'a bien étonné à l'époque.
Le Wed, 29 Aug 2007 09:58:50 +0000, Nicolas George a écrit:
Non non.
Ben si. Par pitié, arrête de parler de ce que tu ne connais pas.
heu, j'ai retrouvé dans mes archives (1997). Type de code correcteur utilisé PGZ (reed solomon). 16 bits codés sur 31 bits GF(32) et j'avais droit à 3 bits d'erreurs. En codant sur 63 bits GF(64), j'avais droit à 9 bits d'erreurs.
Ce code la n'était pas le meilleur, il y avait celui à base d'euclide plus performant mais théoriquement plus complexe. Et si je me souviens bien, sur 15 bits, on pouvait bien avoir 7 bits d'erreur. Je dis 7 selon mes souvenirs, mais ça peut être 6 ou 5 pas moins en tout cas et ça m'a bien étonné à l'époque.
Nicolas George
Arol wrote in message <46d54958$0$9228$:
heu, j'ai retrouvé dans mes archives (1997). Type de code correcteur utilisé PGZ (reed solomon). 16 bits codés sur 31 bits GF(32) et j'avais droit à 3 bits d'erreurs. En codant sur 63 bits GF(64), j'avais droit à 9 bits d'erreurs.
Oui, ces chiffres-là sont raisonnables.
Ce code la n'était pas le meilleur, il y avait celui à base d'euclide plus performant mais théoriquement plus complexe. Et si je me souviens bien, sur 15 bits, on pouvait bien avoir 7 bits d'erreur.
Si tu veux dire : 16 bits de données plus 15 bits supplémentaires, on ne peut pas dépasser 3 bits d'erreur.
Arol wrote in message <46d54958$0$9228$426a74cc@news.free.fr>:
heu, j'ai retrouvé dans mes archives (1997).
Type de code correcteur utilisé PGZ (reed solomon).
16 bits codés sur 31 bits GF(32) et j'avais droit à 3 bits d'erreurs.
En codant sur 63 bits GF(64), j'avais droit à 9 bits d'erreurs.
Oui, ces chiffres-là sont raisonnables.
Ce code la n'était pas le meilleur, il y avait celui à base d'euclide plus
performant mais théoriquement plus complexe.
Et si je me souviens bien, sur 15 bits, on pouvait bien avoir 7 bits
d'erreur.
Si tu veux dire : 16 bits de données plus 15 bits supplémentaires, on ne
peut pas dépasser 3 bits d'erreur.
heu, j'ai retrouvé dans mes archives (1997). Type de code correcteur utilisé PGZ (reed solomon). 16 bits codés sur 31 bits GF(32) et j'avais droit à 3 bits d'erreurs. En codant sur 63 bits GF(64), j'avais droit à 9 bits d'erreurs.
Oui, ces chiffres-là sont raisonnables.
Ce code la n'était pas le meilleur, il y avait celui à base d'euclide plus performant mais théoriquement plus complexe. Et si je me souviens bien, sur 15 bits, on pouvait bien avoir 7 bits d'erreur.
Si tu veux dire : 16 bits de données plus 15 bits supplémentaires, on ne peut pas dépasser 3 bits d'erreur.
Arol
Le Wed, 29 Aug 2007 16:45:09 +0200, Nanar Duff a écrit:
Mais ce que je ne comprends pas, c'est en quoi le Turbo Code vient jouer la dedans. Pour pouvoir récuperer des données avec un "Turbo Décodeur", il ne faut pas que ces données soient d'abord "Turbo Codé" ?! Le disque dur le fait automatiquement ? Ce n'est d'ailleurs pas le même principe pour le codage convolutif, ne faut-il pas d'abord encoder les informations ?
Le turbo code est juste une façon pour de coder les données pour la correction d'erreurs, il est utilisé pour l'adsl2 par exemple. Pour le cdrom, les données sont codées CIRC. En fait un cdrom de 700Mo de données contient 900Mo (je dis ça comme ça) une fois codés. Pour les disque durs, j'ai aucune idée du type de code correcteur utilisé.
Cherche sur le net, tu devrais trouver.
Le Wed, 29 Aug 2007 16:45:09 +0200, Nanar Duff a écrit:
Mais ce que je ne comprends pas, c'est en quoi le Turbo Code vient jouer
la dedans. Pour pouvoir récuperer des données avec un "Turbo Décodeur",
il ne faut pas que ces données soient d'abord "Turbo Codé" ?! Le disque
dur le fait automatiquement ? Ce n'est d'ailleurs pas le même principe
pour le codage convolutif, ne faut-il pas d'abord encoder les informations ?
Le turbo code est juste une façon pour de coder les données pour la
correction d'erreurs, il est utilisé pour l'adsl2 par exemple.
Pour le cdrom, les données sont codées CIRC. En fait un cdrom de 700Mo de
données contient 900Mo (je dis ça comme ça) une fois codés.
Pour les disque durs, j'ai aucune idée du type de code correcteur utilisé.
Le Wed, 29 Aug 2007 16:45:09 +0200, Nanar Duff a écrit:
Mais ce que je ne comprends pas, c'est en quoi le Turbo Code vient jouer la dedans. Pour pouvoir récuperer des données avec un "Turbo Décodeur", il ne faut pas que ces données soient d'abord "Turbo Codé" ?! Le disque dur le fait automatiquement ? Ce n'est d'ailleurs pas le même principe pour le codage convolutif, ne faut-il pas d'abord encoder les informations ?
Le turbo code est juste une façon pour de coder les données pour la correction d'erreurs, il est utilisé pour l'adsl2 par exemple. Pour le cdrom, les données sont codées CIRC. En fait un cdrom de 700Mo de données contient 900Mo (je dis ça comme ça) une fois codés. Pour les disque durs, j'ai aucune idée du type de code correcteur utilisé.
Cherche sur le net, tu devrais trouver.
Nicolas George
Arol wrote in message <46d67f4d$0$20291$:
En fait un cdrom de 700Mo de données contient 900Mo (je dis ça comme ça) une fois codés.
Au lieu de dire ça « comme ça », tu peux donner les valeurs exactes. Un secteur de CD contient 2 ko de données utiles, 288 octets de code correcteur et 16 octets de synchronisation, soit un total de 2352 octets. Donc un CD de 700 Mo fait environ 804 Mo de données brutes.
Ces secteurs sont à leur tour constitués de 98 trames de 24 octets utiles, plus 8 octets de code correcteur, plus un octet de sous-code, soit 33 octets au total. Ce qui fait 1105 Mo pour un CD de 700 Mo.
Je ne sais pas d'où tu as tiré ton 900, mais c'est n'importe quoi.
Un CD audio utilise les 2352 octets des secteurs, sans code correcteur ni information de synchronisation, ce qui lui donne 1/75 s de musique. Un Video-CD utilise les secteurs sans code correcteur, mais avec les informations de synchronisation, soit 2336 octets utiles. Les codes correcteurs au niveau des trames ne peuvent pas être récupérés.
Arol wrote in message <46d67f4d$0$20291$426a34cc@news.free.fr>:
En fait un cdrom de 700Mo de
données contient 900Mo (je dis ça comme ça) une fois codés.
Au lieu de dire ça « comme ça », tu peux donner les valeurs exactes. Un
secteur de CD contient 2 ko de données utiles, 288 octets de code correcteur
et 16 octets de synchronisation, soit un total de 2352 octets. Donc un CD de
700 Mo fait environ 804 Mo de données brutes.
Ces secteurs sont à leur tour constitués de 98 trames de 24 octets utiles,
plus 8 octets de code correcteur, plus un octet de sous-code, soit
33 octets au total. Ce qui fait 1105 Mo pour un CD de 700 Mo.
Je ne sais pas d'où tu as tiré ton 900, mais c'est n'importe quoi.
Un CD audio utilise les 2352 octets des secteurs, sans code correcteur ni
information de synchronisation, ce qui lui donne 1/75 s de musique. Un
Video-CD utilise les secteurs sans code correcteur, mais avec les
informations de synchronisation, soit 2336 octets utiles. Les codes
correcteurs au niveau des trames ne peuvent pas être récupérés.
En fait un cdrom de 700Mo de données contient 900Mo (je dis ça comme ça) une fois codés.
Au lieu de dire ça « comme ça », tu peux donner les valeurs exactes. Un secteur de CD contient 2 ko de données utiles, 288 octets de code correcteur et 16 octets de synchronisation, soit un total de 2352 octets. Donc un CD de 700 Mo fait environ 804 Mo de données brutes.
Ces secteurs sont à leur tour constitués de 98 trames de 24 octets utiles, plus 8 octets de code correcteur, plus un octet de sous-code, soit 33 octets au total. Ce qui fait 1105 Mo pour un CD de 700 Mo.
Je ne sais pas d'où tu as tiré ton 900, mais c'est n'importe quoi.
Un CD audio utilise les 2352 octets des secteurs, sans code correcteur ni information de synchronisation, ce qui lui donne 1/75 s de musique. Un Video-CD utilise les secteurs sans code correcteur, mais avec les informations de synchronisation, soit 2336 octets utiles. Les codes correcteurs au niveau des trames ne peuvent pas être récupérés.
