Equivalence entre durée (mn) et taille (Mo) d'un CD - Page 1

c'est juste une ptite question

en supposant que la qualité d'un CD c'est : 44,1 kHz ; 16 bits ; stéréo, un CD de 74 Min devrait faire :
74 * 60 * 44100 * 2 (pour le stéréo) * 2 (pour la taille de l'échantillon) = 783216000, soit env. 747 Mo

Or c'est > 650 Mo !!!

comment expliquer ça ?
la taille de l'échantillon serait de 14 bits ? (dans ce cas ça fait 653.6 Mo, ce qui est plus cohérent)

Il y a 100Mo de CRC environ sur un CD de 700Mo, d'ou la place perdue
Exemple : sur un CD dit de 700Mo, on peut graver un SVCD de 800Mo, avec des logiciels qui enlevent ces CRC...

ça voudrait dire que sur les 14 bits y'en ait 2 pour le CRC ?

ou alors j'suis à coté de la plaque ?

Ben sais pas trop. Tout ce que je sais c'est qu'une bonne partie du CD est du CRC, après, je sais pas comment c'est fait...
Il se peut que sur un CD audio, il n'y ai pas de CRC, ce qui expliquerait la taille de 747 Mo...
En tous cas, il est certain a 100% qu'un CD est bien echantilloné sur 16 bits et pas 14...

Il n'y a pas de CRC sur un CD audio ??? ça veut dire que le signal qu'on lit est complètement différent du signal enregistré !
Un CD comporte TOUJOURS des poussières !

Bah, je sais pas, mais c'est vraiment etrange...
En fait, je vois pas trop d'autre possibilité...
Il est vrai pourtant qu'un CD Audio n'a pas la fragilité d'un SVCD qui lui, il est certain n'a pas de CRC...

C'est vrai que c'est quand meme très etrange...

Les CDs audio comportent des sommes de contrôle, mais moins que les CD-ROM de données.

goldstar :
c'est juste une ptite question

en supposant que la qualité d'un CD c'est : 44,1 kHz ; 16 bits ; stéréo, un CD de 74 Min devrait faire :
74 * 60 * 44100 * 2 (pour le stéréo) * 2 (pour la taille de l'échantillon) = 783216000, soit env. 747 Mo

Or c'est > 650 Mo !!!

comment expliquer ça ? la taille de l'échantillon serait de 14 bits ? (dans ce cas ça fait 653.6 Mo, ce qui est plus cohérent)

C'est tout simplement parce qu'un CD d'audio n'est pas en *.wav en [44.1-S-16] ...
Ca c'est du 44100 * 2 * 2 = 176400 o/s =~ 172 Ko/s.
Un CD audio, c'est du *.cda à 150 Ko/s (cf. la vitesse d'un lecteur de CD-ROM), d'où :
74 * 60 * 150 = 666000 Ko =~ 650.4 Mo ... le compte est bon !

Si tu regardes la doc des lecteurs de CD-ROM ou ce que dis ton logiciel de gravure, tu verras que 1x = 150 Ko/s, 2x = 300 Ko/s, 4x = 600 Ko/s, ...

@++

Et donc, ce serait codé comment d'après toi? 14 bits? (ça a l'air de bien coller, mais c'est vraiment pas top comme résolution... alors quand je vois des plugins 24 bits pour décoder des MP3 et des tests qui parlent de "qualité bien meilleure", ça me fait bien marrer )

C'est KK qui a - encore - raison...
LA première démo faite par Philips pour leurs CD audio, c'était demander aux gens de s'amuser à détériorer le CD audio et ensuite de vérifier que tout marchait encore. Et c'était le cas.
Faut voir que sur un CD, la correction des erreurs est fantastique. C'est pas 650Mo que tu mets dessus, mais vraissemblablement plus proche du double au vue de la correction qui est déjà là pour l'audio. Sachant que pour l'audio, une erreur est moins grave que pour un programme, ça explique l'amélioration des codes correcteurs. Et pour finir, je ne conseille pas d'utiliser les méthodes de 'suppression' des CRC, c'est pas malin pour le peu de place que ça apporte par rapport au nombre d'erreurs non détectées.

Pourquoi ça apporte si peu de place si la moitié du CD est du code de contrôle ?

Thibaut B
: Pourquoi ça apporte si peu de place si la moitié du CD est du code de contrôle ?

parce qu'ils ne sont pas malades au point de tout virer - patate -, le graveur te met d'office des erreurs dessus parce qu'il n'est pas parfait, et ceci d'autant plus que la vitesse est élevée. Donc c'est suicidaire de ne pas mettre de code correcteur - même sur ton disque dur, il y en a plein, alors sur un disque exposé à l'environnement extérieur... -

Alors si on peut en virer qu'une partie, concrètement, comme fonctionne ce code de contrôle ?
Je vais interroger mon ami Google et rapporter si je trouve des choses.

Plus on a de bits de sommes de contrôle (calculées différemment - il faut que les vecteurs (sur l'anneau ({0,1},XOR,AND) isomorphe à Z/2Z) utilisés pour le produit scalaire (généralisé aux espaces vectoriels sur des anneaux) soient linéairement indépendants pour que ce soit efficace), plus on peut détecter ou corriger d'erreurs.

Merci j'ai tout compris

Soit un octet (bits 0, ..., 7). Si tu prends:
* une somme de contrôle sur les bits 0, 1, 2, 3, 4, 5, 6 (donc vecteur [1,1,1,1,1,1,1,0])
* une somme de contrôle sur les bits 1, 2, 3, 4, 5, 6, 7 (donc vecteur [0,1,1,1,1,1,1,1])
* une somme de contrôle sur les bits 0 et 7 (donc vecteur [1,0,0,0,0,0,0,1])
c'est mauvais, parce que [1,1,1,1,1,1,1,0] bitwiseXOR [0,1,1,1,1,1,1,1] = [1,0,0,0,0,0,0,1], donc tes vecteurs sont linéairement dépendants.
En revanche:
* une somme de contrôle sur les bits 0, 3, 6 (donc vecteur [1,0,0,1,0,0,1,0])
* une somme de contrôle sur les bits 1, 4, 7 (donc vecteur [0,1,0,0,1,0,0,1])
* une somme de contrôle sur les bits 2 et 5 (donc vecteur [0,0,1,0,0,1,0,0])
est mieux, parce que les vecteurs sont linéairement indépendants.

moi j'avais bien compris ton premier post, par contre, ça marche comment un CRC en pratique
je veux dire comment avec un octet de contrôle et la donnée on vérifie l'intégrité?
si ça se trouve sur le net, et que vous connaissez une url...

On n'a pas tous son niveau en maths, sa réponse est le genre de posts à éviter sur un forum hétérogène... Merci d'avoir rééxpliqué Kev'

(généralisé aux espaces vectoriels sur des anneaux)

Z/2Z est un corps, mon jeune ami.

janjan2> tu prends le vecteur valide le plus "proche" (au sens de la distance de Hamming, i.e. la distance entre x1 et x2 est le nombre de bits différents dans x1 et x2). Le problème se situe plutôt au niveau de la génération de ton ensemble de points. Pour que tu puisses avoir la moindre correction d'erreur, il faut qu'il y ait au moins une distance de 3 entre chaque couple (x1,x2) de vecteurs (sinon, si la distance est <=2, alors il existe un point à une distance <=1 de x1 et <=1 de x2, ce qui veut dire que la moindre erreur sur ce bit-là entraîne une ambiguïté). Après, t'as plein de formes diverses, avec des propriétés mathématiques particulières pour faciliter la génération du code.

Un truc que l'exemple de Kevin ne montre pas, c'est que cette distance entre chaque couple (x1,x2) doit non seulement être >=3, mais qu'il vaut mieux que la borne inférieure d de toutes ces distances soit la plus grande possible (sinon, c'est pas trop la peine d'avoir une très grande distance entre 90% des points mais que 10% des points soit à une distance de 3 l'un de l'autre). Avoir d = 2n+1 signifie intuitivement qu'on peut corriger n erreurs sur les bits; on a aussi une relation entre la quantité de bits de donnée utile p et la quantité de données code correcteur comprise q : q >= q_min = p + log(d)/log(2). Tout l'art du code correcteur étant bien sûr d'avoir q et q_min aussi proches que possible, mais sans avoir besoin de 3 Go de lookup-tables pour coder ou décoder (d'où l'intérêt des propriétés mathématiques bizarres).

Pollux
:

(généralisé aux espaces vectoriels sur des anneaux)

Z/2Z est un corps, mon jeune ami.

En effet (bien vu ). Mais il faut quand-même le généraliser à des espaces vectoriels sur des corps arbitraires. (En général, on définit le produit scalaire sur |R et (C seulement. Et certaines propriétés de l'orthogonalité et du produit scalaire valables pour des espaces vectoriels sur |R et (C ne le sont plus pour des espaces vectoriels sur un corps comme Z/2Z. Par exemple, sur (Z/2Z)ⁿ, un vecteur non nul peut être orthogonal à lui-même. Il y en a même plein: il suffit qu'il ait un nombre impair de bits à 1.)

Pour avoir (distraitement) suivi un cours de codes correcteurs l'an dernier, il y a effectivement deux fois plus de données brutes sur un CD que ce qui est indiqué, la moitié est composé de codes correcteurs. Un CD serait absolument inutilisable sans cette correction.

(En général, on définit le produit scalaire sur |R et (C seulement.

Non

Si on veut des propriétés comme x.x=0 => x=0, alors si.

En caractéristique non nulle, on a effectivement des problèmes pour parler de formes définies (x.x=0 => x=0)

Mais pour les corps de caractéristiques nulles, ça ne pose pas de problème (Q, corps de nombres, corps des nombres algébriques, Qp, Qp-barre, k(X), .....)

Bah de toute façon ça n'empêche pas de définir un produit scalaire... ça fait juste qu'il n'en existe pas

En caractéristique non nulle on a quand même du mal à définir la propriété de positivité... Disons qu'il faut partir d'un corps ordonné, alors...
Bon d'accord, c'est juste qu'il n'y en a pas...

Donc pour qu'il y en ait un (et le produit scalaire sur (Z/2Z)ⁿ est utile en Informatique), il faut généraliser la définition.

Ce n'est plus un produit scalaire. C'est une simple forme bilinéaire!

Ben si tu généralises en disant que c'est pas forcément défini ni positif, ce que tu appelles produit scalaire n'est plus autre qu'une forme bilinéaire quelconque, donc autant appeler ça par son nom

Euh, Kevin, je vois pas de quel produit scalaire tu parles. La distance de Hamming est la norme 1, point. Où vois-tu un produit scalaire ou des trucs orthogonaux?

Dès qu'on a une forme bilinéaire (quelconque), on peut parler d'orthogonalité.