Sans trop rentrer dans les détails, les encodages avec pertes utilisent une compression avec perte suivit d'une compression sans perte. Si deux formats utilisent le même algorythme de compression avec perte, mais un algorythme de compression sans perte différent et un format de fichier différent, alors on peut faire du transcodage sans pertes entre les deux formats.
C'est la théorie. En pratique, des encodeurs différents produiront des MP3 différents même si les paramètres sont les même. Idem pour l'AAC. Cela vient du fait que seul le flux compressé est normalisé, et non pas la marche à suive pour l'obtenir.
Patrick -- Patrick Stadelmann
In article <ciq6nt$svq$5@news.polytechnique.fr>, Schmurtz <moi@ici.com>
wrote:
Sans trop rentrer dans les détails, les encodages avec pertes utilisent
une compression avec perte suivit d'une compression sans perte. Si deux
formats utilisent le même algorythme de compression avec perte, mais un
algorythme de compression sans perte différent et un format de fichier
différent, alors on peut faire du transcodage sans pertes entre les deux
formats.
C'est la théorie. En pratique, des encodeurs différents produiront des
MP3 différents même si les paramètres sont les même. Idem pour l'AAC.
Cela vient du fait que seul le flux compressé est normalisé, et non pas
la marche à suive pour l'obtenir.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Sans trop rentrer dans les détails, les encodages avec pertes utilisent une compression avec perte suivit d'une compression sans perte. Si deux formats utilisent le même algorythme de compression avec perte, mais un algorythme de compression sans perte différent et un format de fichier différent, alors on peut faire du transcodage sans pertes entre les deux formats.
C'est la théorie. En pratique, des encodeurs différents produiront des MP3 différents même si les paramètres sont les même. Idem pour l'AAC. Cela vient du fait que seul le flux compressé est normalisé, et non pas la marche à suive pour l'obtenir.
Patrick -- Patrick Stadelmann
Schmurtz
Saïd wrote:
Je repete ce que j'ai deja dit plusieurs fois: Il est impossible de donner a la fois a l'utilisateur un fichier crypte et le logiciel qui decrypte (pour lire la musique) si on veut que le cryptage ne soit pas casse. Exemple les DVD qui sont supposes cryptes mais que l'on peut decrypter tres facilement.
Dans le cas d'iTunes, la clé de décryptage est stocké sur le disque de l'utilisateur : il faut bien, pour qu'il puisse lire ses musiques par exemple.
Ces protections ne sont que des leurres, je ne comprends meme pas qu'elles existent. Les concepteurs doivent profiter de la naivete de leurs clients...
Bien sûr, d'ailleurs Apple passe son temps à modifier son format afin de le rendre incompatible avec les logiciels "pirates".
Il existe des protections sûres, par exemple le projet paladium de microsoft et cie.
Dans ce cas, la sécurité est centralisé dans une puce qui contient une clé de vérification de signature A identique sur toutes les puces et une clef de cryptage B unique pour chaque puce. La machine en question n'autorise de lancer que des OS qui ont été signé avec cette clé A, donc uniquement un OS qui à été autorisé par le fabriquant de la puce.
Le système peut autoriser à des applis choisies (et signées pour vérifier quelles n'ont pas été modifiées par un tier) à utiliser la clé B, par exemple pour décrypter une musique.
En théorie (s'il n'y a pas de bugs), il n'y a donc qu'une seule machine dans le monde qui peut lire ce fichier musical ! si l'OS est complètement verrouillé, il peut empêcher tous les moyens d'interceptions du signal sonore par un logiciel/driver et donc la seule solution est de récupérer le signal sonore à la sortie des HP. On peut imaginer encore plus complexe et bridé, mais c'est pas très utile.
-- Schmurtz
Saïd <said@brian.lan> wrote:
Je repete ce que j'ai deja dit plusieurs fois: Il est impossible de donner
a la fois a l'utilisateur un fichier crypte et le logiciel qui decrypte
(pour lire la musique) si on veut que le cryptage ne soit pas casse. Exemple
les DVD qui sont supposes cryptes mais que l'on peut decrypter tres
facilement.
Dans le cas d'iTunes, la clé de décryptage est stocké sur le disque de
l'utilisateur : il faut bien, pour qu'il puisse lire ses musiques par
exemple.
Ces protections ne sont que des leurres, je ne comprends meme pas qu'elles
existent. Les concepteurs doivent profiter de la naivete de leurs clients...
Bien sûr, d'ailleurs Apple passe son temps à modifier son format afin de
le rendre incompatible avec les logiciels "pirates".
Il existe des protections sûres, par exemple le projet paladium de
microsoft et cie.
Dans ce cas, la sécurité est centralisé dans une puce qui contient une
clé de vérification de signature A identique sur toutes les puces et une
clef de cryptage B unique pour chaque puce. La machine en question
n'autorise de lancer que des OS qui ont été signé avec cette clé A, donc
uniquement un OS qui à été autorisé par le fabriquant de la puce.
Le système peut autoriser à des applis choisies (et signées pour
vérifier quelles n'ont pas été modifiées par un tier) à utiliser la clé
B, par exemple pour décrypter une musique.
En théorie (s'il n'y a pas de bugs), il n'y a donc qu'une seule machine
dans le monde qui peut lire ce fichier musical ! si l'OS est
complètement verrouillé, il peut empêcher tous les moyens
d'interceptions du signal sonore par un logiciel/driver et donc la seule
solution est de récupérer le signal sonore à la sortie des HP. On peut
imaginer encore plus complexe et bridé, mais c'est pas très utile.
Je repete ce que j'ai deja dit plusieurs fois: Il est impossible de donner a la fois a l'utilisateur un fichier crypte et le logiciel qui decrypte (pour lire la musique) si on veut que le cryptage ne soit pas casse. Exemple les DVD qui sont supposes cryptes mais que l'on peut decrypter tres facilement.
Dans le cas d'iTunes, la clé de décryptage est stocké sur le disque de l'utilisateur : il faut bien, pour qu'il puisse lire ses musiques par exemple.
Ces protections ne sont que des leurres, je ne comprends meme pas qu'elles existent. Les concepteurs doivent profiter de la naivete de leurs clients...
Bien sûr, d'ailleurs Apple passe son temps à modifier son format afin de le rendre incompatible avec les logiciels "pirates".
Il existe des protections sûres, par exemple le projet paladium de microsoft et cie.
Dans ce cas, la sécurité est centralisé dans une puce qui contient une clé de vérification de signature A identique sur toutes les puces et une clef de cryptage B unique pour chaque puce. La machine en question n'autorise de lancer que des OS qui ont été signé avec cette clé A, donc uniquement un OS qui à été autorisé par le fabriquant de la puce.
Le système peut autoriser à des applis choisies (et signées pour vérifier quelles n'ont pas été modifiées par un tier) à utiliser la clé B, par exemple pour décrypter une musique.
En théorie (s'il n'y a pas de bugs), il n'y a donc qu'une seule machine dans le monde qui peut lire ce fichier musical ! si l'OS est complètement verrouillé, il peut empêcher tous les moyens d'interceptions du signal sonore par un logiciel/driver et donc la seule solution est de récupérer le signal sonore à la sortie des HP. On peut imaginer encore plus complexe et bridé, mais c'est pas très utile.
-- Schmurtz
Patrick Stadelmann
In article , Saïd wrote:
Ben, si. Je ne connais pas les formats, mais s'ils reposent sur le meme type de compressione
Ce n'est pas le cas. Même si la théorie et les principes généraux sont les mêmes, il n'y a probablement aucun moyen de passer de l'un à l'autre qui donne un meilleur résultat (en termes de qualité) que de décoder et de recompresser. Si l'on connaît les deux algorithmes, on pourrait éventuellement optimiser les paramètres du second pour l'adapter le mieux possible aux caractéristiques du morceau généré par la compression-décompression avec le premier algorithme.
Patrick -- Patrick Stadelmann
In article <slrncl0ea8.1mc.said@brian.lan>, Saïd <said@brian.lan>
wrote:
Ben, si. Je ne connais pas les formats, mais s'ils reposent sur le meme type
de compressione
Ce n'est pas le cas. Même si la théorie et les principes généraux sont
les mêmes, il n'y a probablement aucun moyen de passer de l'un à l'autre
qui donne un meilleur résultat (en termes de qualité) que de décoder et
de recompresser. Si l'on connaît les deux algorithmes, on pourrait
éventuellement optimiser les paramètres du second pour l'adapter le
mieux possible aux caractéristiques du morceau généré par la
compression-décompression avec le premier algorithme.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Ben, si. Je ne connais pas les formats, mais s'ils reposent sur le meme type de compressione
Ce n'est pas le cas. Même si la théorie et les principes généraux sont les mêmes, il n'y a probablement aucun moyen de passer de l'un à l'autre qui donne un meilleur résultat (en termes de qualité) que de décoder et de recompresser. Si l'on connaît les deux algorithmes, on pourrait éventuellement optimiser les paramètres du second pour l'adapter le mieux possible aux caractéristiques du morceau généré par la compression-décompression avec le premier algorithme.
Patrick -- Patrick Stadelmann
Saïd
Schmurtz :
Il existe des protections sûres, par exemple le projet paladium de microsoft et cie.
Comptent-ils permettre la possibilite de lancer autre chose que windoze sur des machines paladium?
Dans ce cas, la sécurité est centralisé dans une puce qui contient une clé de vérification de signature A identique sur toutes les puces et une clef de cryptage B unique pour chaque puce. La machine en question n'autorise de lancer que des OS qui ont été signé avec cette clé A, donc uniquement un OS qui à été autorisé par le fabriquant de la puce.
J'espere qu'on verra apparaitre des puces de remplacement "pirates" et des bidouilleurs pour deplomber le bouzin.
Le système peut autoriser à des applis choisies (et signées pour vérifier quelles n'ont pas été modifiées par un tier) à utiliser la clé B, par exemple pour décrypter une musique.
En théorie (s'il n'y a pas de bugs), il n'y a donc qu'une seule machine dans le monde qui peut lire ce fichier musical ! si l'OS est complètement verrouillé, il peut empêcher tous les moyens d'interceptions du signal sonore par un logiciel/driver et donc la seule solution est de récupérer le signal sonore à la sortie des HP. On peut imaginer encore plus complexe et bridé, mais c'est pas très utile.
Le jour ou ca arrive j'arrete l'informatique sauf pour raisons professionnelles et on pourra compter sur moi pour raler contre tout service qui ne serait accessibles qu'a ceux qui possendent un ordinateur.
-- Saïd. C programmers never die - they're just cast into void.
Schmurtz :
Il existe des protections sûres, par exemple le projet paladium de
microsoft et cie.
Comptent-ils permettre la possibilite de lancer autre chose que windoze sur
des machines paladium?
Dans ce cas, la sécurité est centralisé dans une puce qui contient une
clé de vérification de signature A identique sur toutes les puces et une
clef de cryptage B unique pour chaque puce. La machine en question
n'autorise de lancer que des OS qui ont été signé avec cette clé A, donc
uniquement un OS qui à été autorisé par le fabriquant de la puce.
J'espere qu'on verra apparaitre des puces de remplacement "pirates" et des
bidouilleurs pour deplomber le bouzin.
Le système peut autoriser à des applis choisies (et signées pour
vérifier quelles n'ont pas été modifiées par un tier) à utiliser la clé
B, par exemple pour décrypter une musique.
En théorie (s'il n'y a pas de bugs), il n'y a donc qu'une seule machine
dans le monde qui peut lire ce fichier musical ! si l'OS est
complètement verrouillé, il peut empêcher tous les moyens
d'interceptions du signal sonore par un logiciel/driver et donc la seule
solution est de récupérer le signal sonore à la sortie des HP. On peut
imaginer encore plus complexe et bridé, mais c'est pas très utile.
Le jour ou ca arrive j'arrete l'informatique sauf pour raisons
professionnelles et on pourra compter sur moi pour raler contre tout service
qui ne serait accessibles qu'a ceux qui possendent un ordinateur.
--
Saïd.
C programmers never die - they're just cast into void.
Il existe des protections sûres, par exemple le projet paladium de microsoft et cie.
Comptent-ils permettre la possibilite de lancer autre chose que windoze sur des machines paladium?
Dans ce cas, la sécurité est centralisé dans une puce qui contient une clé de vérification de signature A identique sur toutes les puces et une clef de cryptage B unique pour chaque puce. La machine en question n'autorise de lancer que des OS qui ont été signé avec cette clé A, donc uniquement un OS qui à été autorisé par le fabriquant de la puce.
J'espere qu'on verra apparaitre des puces de remplacement "pirates" et des bidouilleurs pour deplomber le bouzin.
Le système peut autoriser à des applis choisies (et signées pour vérifier quelles n'ont pas été modifiées par un tier) à utiliser la clé B, par exemple pour décrypter une musique.
En théorie (s'il n'y a pas de bugs), il n'y a donc qu'une seule machine dans le monde qui peut lire ce fichier musical ! si l'OS est complètement verrouillé, il peut empêcher tous les moyens d'interceptions du signal sonore par un logiciel/driver et donc la seule solution est de récupérer le signal sonore à la sortie des HP. On peut imaginer encore plus complexe et bridé, mais c'est pas très utile.
Le jour ou ca arrive j'arrete l'informatique sauf pour raisons professionnelles et on pourra compter sur moi pour raler contre tout service qui ne serait accessibles qu'a ceux qui possendent un ordinateur.
-- Saïd. C programmers never die - they're just cast into void.
Saïd
Patrick Stadelmann :
In article , Saïd wrote:
Ben, si. Je ne connais pas les formats, mais s'ils reposent sur le meme type de compressione
Ce n'est pas le cas. Même si la théorie et les principes généraux sont les mêmes, il n'y a probablement aucun moyen de passer de l'un à l'autre qui donne un meilleur résultat (en termes de qualité) que de décoder et de recompresser. Si l'on connaît les deux algorithmes, on pourrait éventuellement optimiser les paramètres du second pour l'adapter le mieux possible aux caractéristiques du morceau généré par la compression-décompression avec le premier algorithme.
Ok, donc gravage -> puis recompression. si j'achete sur fnacmusic. Merci pour la precision.
-- Saïd. C programmers never die - they're just cast into void.
Patrick Stadelmann :
In article <slrncl0ea8.1mc.said@brian.lan>, Saïd <said@brian.lan>
wrote:
Ben, si. Je ne connais pas les formats, mais s'ils reposent sur le meme type
de compressione
Ce n'est pas le cas. Même si la théorie et les principes généraux sont
les mêmes, il n'y a probablement aucun moyen de passer de l'un à l'autre
qui donne un meilleur résultat (en termes de qualité) que de décoder et
de recompresser. Si l'on connaît les deux algorithmes, on pourrait
éventuellement optimiser les paramètres du second pour l'adapter le
mieux possible aux caractéristiques du morceau généré par la
compression-décompression avec le premier algorithme.
Ok, donc gravage -> puis recompression. si j'achete sur fnacmusic. Merci
pour la precision.
--
Saïd.
C programmers never die - they're just cast into void.
Ben, si. Je ne connais pas les formats, mais s'ils reposent sur le meme type de compressione
Ce n'est pas le cas. Même si la théorie et les principes généraux sont les mêmes, il n'y a probablement aucun moyen de passer de l'un à l'autre qui donne un meilleur résultat (en termes de qualité) que de décoder et de recompresser. Si l'on connaît les deux algorithmes, on pourrait éventuellement optimiser les paramètres du second pour l'adapter le mieux possible aux caractéristiques du morceau généré par la compression-décompression avec le premier algorithme.
Ok, donc gravage -> puis recompression. si j'achete sur fnacmusic. Merci pour la precision.
-- Saïd. C programmers never die - they're just cast into void.
Patrick Stadelmann
In article <ciq7vl$svq$, Schmurtz wrote:
Bien sûr, d'ailleurs Apple passe son temps à modifier son format afin de le rendre incompatible avec les logiciels "pirates".
Il y a eu UNE fois une modification, et mineure de plus. Il y a aussi eu une modification dans iTunes pour qu'il refuse de lire des AAC qu'il identifiait comme ayant été déprotégés.
Patrick -- Patrick Stadelmann
In article <ciq7vl$svq$8@news.polytechnique.fr>, Schmurtz <moi@ici.com>
wrote:
Bien sûr, d'ailleurs Apple passe son temps à modifier son format afin de
le rendre incompatible avec les logiciels "pirates".
Il y a eu UNE fois une modification, et mineure de plus. Il y a aussi eu
une modification dans iTunes pour qu'il refuse de lire des AAC qu'il
identifiait comme ayant été déprotégés.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Bien sûr, d'ailleurs Apple passe son temps à modifier son format afin de le rendre incompatible avec les logiciels "pirates".
Il y a eu UNE fois une modification, et mineure de plus. Il y a aussi eu une modification dans iTunes pour qu'il refuse de lire des AAC qu'il identifiait comme ayant été déprotégés.
Patrick -- Patrick Stadelmann
c.demeester
Saïd wrote:
Patrick Stadelmann : > In article , Saïd > wrote: > >> Ben, si. Je ne connais pas les formats, mais s'ils reposent sur le meme type >> de compressione > > Ce n'est pas le cas. Même si la théorie et les principes généraux sont > les mêmes, il n'y a probablement aucun moyen de passer de l'un à l'autre > qui donne un meilleur résultat (en termes de qualité) que de décoder et > de recompresser. Si l'on connaît les deux algorithmes, on pourrait > éventuellement optimiser les paramètres du second pour l'adapter le > mieux possible aux caractéristiques du morceau généré par la > compression-décompression avec le premier algorithme. >
Ok, donc gravage -> puis recompression. si j'achete sur fnacmusic. Merci pour la precision.
Patrick Stadelmann : > In article <slrncl0ea8.1mc.said@brian.lan>, Saïd
<said@brian.lan> > wrote: > >> Ben, si. Je ne connais pas les formats,
mais s'ils reposent sur le meme type >> de compressione > > Ce n'est pas
le cas. Même si la théorie et les principes généraux sont > les mêmes, il
n'y a probablement aucun moyen de passer de l'un à l'autre > qui donne un
meilleur résultat (en termes de qualité) que de décoder et > de
recompresser. Si l'on connaît les deux algorithmes, on pourrait >
éventuellement optimiser les paramètres du second pour l'adapter le >
mieux possible aux caractéristiques du morceau généré par la >
compression-décompression avec le premier algorithme. >
Ok, donc gravage -> puis recompression. si j'achete sur fnacmusic. Merci
pour la precision.
Patrick Stadelmann : > In article , Saïd > wrote: > >> Ben, si. Je ne connais pas les formats, mais s'ils reposent sur le meme type >> de compressione > > Ce n'est pas le cas. Même si la théorie et les principes généraux sont > les mêmes, il n'y a probablement aucun moyen de passer de l'un à l'autre > qui donne un meilleur résultat (en termes de qualité) que de décoder et > de recompresser. Si l'on connaît les deux algorithmes, on pourrait > éventuellement optimiser les paramètres du second pour l'adapter le > mieux possible aux caractéristiques du morceau généré par la > compression-décompression avec le premier algorithme. >
Ok, donc gravage -> puis recompression. si j'achete sur fnacmusic. Merci pour la precision.
Ok, donc gravage -> puis recompression. si j'achete sur fnacmusic. Merci pour la precision.
Si tu veux éviter toute perte par rapport au fichier original de la FNAC, il suffit de réencoder en Apple Lossless (évidemment, les fichiers seront plus volumineux).
Patrick -- Patrick Stadelmann
In article <slrncl0h93.1o3.said@brian.lan>, Saïd <said@brian.lan>
wrote:
Ok, donc gravage -> puis recompression. si j'achete sur fnacmusic. Merci
pour la precision.
Si tu veux éviter toute perte par rapport au fichier original de la
FNAC, il suffit de réencoder en Apple Lossless (évidemment, les fichiers
seront plus volumineux).
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Ok, donc gravage -> puis recompression. si j'achete sur fnacmusic. Merci pour la precision.
Si tu veux éviter toute perte par rapport au fichier original de la FNAC, il suffit de réencoder en Apple Lossless (évidemment, les fichiers seront plus volumineux).
Patrick -- Patrick Stadelmann
pdorange
Saïd wrote:
Je ne saurais pas le démontrer, mais intuitivement il me semble impossible de convertir un format compressé en un autre sans passer par une décompression/ recompression, donc une perte de données supplémentaire.
Ben, si.
Ben non :-)
Je ne connais pas les formats, mais s'ils reposent sur le meme type de compressione
Justement c'est pas le cas... Fnac = WMA et iTMS = AAC; donc réencodage obligatoire de toute façon.
et que la protction consiste en un cryptage apres compression, il "suffit" de decrypter le contenu compresser pour obtenir une version compressee qui a exactement le meme rendu que la version compresse-cryptee et qui peut etre lue sur n'importe quelle appareil.
Le "il suffit" est en plus très difficile dans ce cas et illégal.
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
Saïd <said@brian.lan> wrote:
Je ne saurais pas le démontrer, mais intuitivement il me semble
impossible de convertir un format compressé en un autre sans passer par
une décompression/ recompression, donc une perte de données
supplémentaire.
Ben, si.
Ben non :-)
Je ne connais pas les formats, mais s'ils reposent sur le meme type
de compressione
Justement c'est pas le cas... Fnac = WMA et iTMS = AAC; donc réencodage
obligatoire de toute façon.
et que la protction consiste en un cryptage apres
compression, il "suffit" de decrypter le contenu compresser pour obtenir une
version compressee qui a exactement le meme rendu que la version
compresse-cryptee et qui peut etre lue sur n'importe quelle appareil.
Le "il suffit" est en plus très difficile dans ce cas et illégal.
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st>
Clarus, the DogCow <www.clarus.mac-fan.com>
Je ne saurais pas le démontrer, mais intuitivement il me semble impossible de convertir un format compressé en un autre sans passer par une décompression/ recompression, donc une perte de données supplémentaire.
Ben, si.
Ben non :-)
Je ne connais pas les formats, mais s'ils reposent sur le meme type de compressione
Justement c'est pas le cas... Fnac = WMA et iTMS = AAC; donc réencodage obligatoire de toute façon.
et que la protction consiste en un cryptage apres compression, il "suffit" de decrypter le contenu compresser pour obtenir une version compressee qui a exactement le meme rendu que la version compresse-cryptee et qui peut etre lue sur n'importe quelle appareil.
Le "il suffit" est en plus très difficile dans ce cas et illégal.
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
Saïd
Pierre-Alain Dorange :
Saïd wrote:
Je ne saurais pas le démontrer, mais intuitivement il me semble impossible de convertir un format compressé en un autre sans passer par une décompression/ recompression, donc une perte de données supplémentaire.
Ben, si.
Ben non :-)
Ben si. Theoriquement. ;-)
Je ne connais pas les formats, mais s'ils reposent sur le meme type de compressione
Justement c'est pas le cas... Fnac = WMA et iTMS = AAC; donc réencodage obligatoire de toute façon.
Oui, ca a ete explique par Patrick.
et que la protction consiste en un cryptage apres compression, il "suffit" de decrypter le contenu compresser pour obtenir une version compressee qui a exactement le meme rendu que la version compresse-cryptee et qui peut etre lue sur n'importe quelle appareil.
Le "il suffit" est en plus très difficile dans ce cas et illégal.
Le cote illegal ne me gene pas, ca fait bien longtemps (depuis que je ne me sers plus de windoze) que je suis hors la loi avec mon lecteur DVD sous linux qui utilise des algos illegaux pour lire les DVD cryptes.
-- Saïd. C programmers never die - they're just cast into void.
Pierre-Alain Dorange :
Saïd <said@brian.lan> wrote:
Je ne saurais pas le démontrer, mais intuitivement il me semble
impossible de convertir un format compressé en un autre sans passer par
une décompression/ recompression, donc une perte de données
supplémentaire.
Ben, si.
Ben non :-)
Ben si. Theoriquement. ;-)
Je ne connais pas les formats, mais s'ils reposent sur le meme type
de compressione
Justement c'est pas le cas... Fnac = WMA et iTMS = AAC; donc réencodage
obligatoire de toute façon.
Oui, ca a ete explique par Patrick.
et que la protction consiste en un cryptage apres
compression, il "suffit" de decrypter le contenu compresser pour obtenir une
version compressee qui a exactement le meme rendu que la version
compresse-cryptee et qui peut etre lue sur n'importe quelle appareil.
Le "il suffit" est en plus très difficile dans ce cas et illégal.
Le cote illegal ne me gene pas, ca fait bien longtemps (depuis que je ne me
sers plus de windoze) que je suis hors la loi avec mon lecteur DVD sous
linux qui utilise des algos illegaux pour lire les DVD cryptes.
--
Saïd.
C programmers never die - they're just cast into void.
Je ne saurais pas le démontrer, mais intuitivement il me semble impossible de convertir un format compressé en un autre sans passer par une décompression/ recompression, donc une perte de données supplémentaire.
Ben, si.
Ben non :-)
Ben si. Theoriquement. ;-)
Je ne connais pas les formats, mais s'ils reposent sur le meme type de compressione
Justement c'est pas le cas... Fnac = WMA et iTMS = AAC; donc réencodage obligatoire de toute façon.
Oui, ca a ete explique par Patrick.
et que la protction consiste en un cryptage apres compression, il "suffit" de decrypter le contenu compresser pour obtenir une version compressee qui a exactement le meme rendu que la version compresse-cryptee et qui peut etre lue sur n'importe quelle appareil.
Le "il suffit" est en plus très difficile dans ce cas et illégal.
Le cote illegal ne me gene pas, ca fait bien longtemps (depuis que je ne me sers plus de windoze) que je suis hors la loi avec mon lecteur DVD sous linux qui utilise des algos illegaux pour lire les DVD cryptes.
-- Saïd. C programmers never die - they're just cast into void.
