Sur les conseils de Nicolas, j'ai enregistré quelques flux T-DMB sur mon PC
avec une DRBOX1 et WinDAB. Pour ce récepteur DAB ancienne génération qui
ignore tout du DMB, ces flux sont vus comme des data stream et peuvent
effectivement être sauvegardés tels quels sur un ordinateur. La vitesse de
download des fichiers sous Firefox correspond effectivement au débit des
subchannels. Donc jusque là, rien de déconnant. Par contre, l'encodage Reed
Solomon qui a été ajouté en DMB et qui n'existait pas en DAB, la DRBOX le
traite comment ?
Le problème, c'est d'essayer de récupérer quelque chose de ces fichiers par
la suite (qui ont l'extension .mpg)
Comme dit, précédemment, rien à faire avec VLC, les fichiers sont
illisibles. Le soft ne plante pas mais il ne décode rien du tout.
Idem avec Nero Showtime qui lui plante carrément.
J'ai essayé de passer ces fichiers dans un démultiplexeur MPEG TS, (TS
Reader, EMUX Pro), là encore TS Reader m'indique près d'une cinquantaine de
PID dans le flux (DSS Packet) avec des débits qui semblent tous faux et Emux
Pro refuse carrément d'ouvrir les fichiers quand il ne plante pas !
J'ai même essayé d'ajouter un header AAC V2 en début de fichier avec un
éditeur hexadécimal pour tenter de voir si le fichier s'ouvrait dans VLC,
oui mais rien d'audible ! C'est pour ça que je me demande si ces fichiers
sont vraiment des multiplexs MPEG2 TS vu qu'aucun soft censé être spécialisé
dans ce domaine n'arrive à les lire. Du coup, je me demandais s'il ne
resterait pas l'encodage correcteur d'erreur Reed Solomon qui rendait ces
fichiers complètement illisibles.
Une rapide recherche sur Google montre qu'il n'existe aucun player DMB sur
PC en téléchargement... Eventuellement, quelques pages sur des sites tous
Coréens, mais vu qu'on ne comprend rien....
Bref, y a t-il une solution pour au moins démultiplexer ces fichiers et en
récupérer l'audio et la vidéo ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas Croiset
"Zeldus" wrote :
Bonsoir,
Sur les conseils de Nicolas, j'ai enregistré quelques flux T-DMB sur mon PC avec une DRBOX1 et WinDAB. Pour ce récepteur DAB ancienne génération qui ignore tout du DMB, ces flux sont vus comme des data stream et peuvent effectivement être sauvegardés tels quels sur un ordinateur. La vitesse de download des fichiers sous Firefox correspond effectivement au débit des subchannels. Donc jusque là, rien de déconnant. Par contre, l'encodage Reed Solomon qui a été ajouté en DMB et qui n'existait pas en DAB, la DRBOX le traite comment ?
Salut,
la DR-BOX 1 n'a pas à traiter le reed solomon, c'est au player en aval de le traiter.
Le flux que tu récupères grâce à la DR-BOX 1 est un TS204 avec l'octet de synchronisation 0x47 comme indiqué dans la TS102427. Si tu fais une rechercher sur cet octet avec un éditeurs hexa tu le retrouveras bien tous les 204 octets.
Le problème, c'est d'essayer de récupérer quelque chose de ces fichiers par la suite (qui ont l'extension .mpg)
Comme dit, précédemment, rien à faire avec VLC, les fichiers sont illisibles. Le soft ne plante pas mais il ne décode rien du tout. Idem avec Nero Showtime qui lui plante carrément. J'ai essayé de passer ces fichiers dans un démultiplexeur MPEG TS, (TS Reader, EMUX Pro), là encore TS Reader m'indique près d'une cinquantaine de PID dans le flux (DSS Packet) avec des débits qui semblent tous faux et Emux Pro refuse carrément d'ouvrir les fichiers quand il ne plante pas !
Tous ces produits ne savent pas décoder la couche SL. Par contre tu peux toujours leur envoyer quelques flux pour qu'ils améliorent leurs produits ;-)
Une rapide recherche sur Google montre qu'il n'existe aucun player DMB sur PC en téléchargement... Eventuellement, quelques pages sur des sites tous Coréens, mais vu qu'on ne comprend rien....
Bref, y a t-il une solution pour au moins démultiplexer ces fichiers et en récupérer l'audio et la vidéo ?
Il faut modifier videolan pour qu'il puisse interpréter la couche SL, je sais que certains ont essayé de le faire car ils sont arrivés à avoir au moins une image. Je ne sais pas si le travail effectué a déjà été commité dans les sources videolan, par contre tu peux éventuellement trouver de l'aide sur le forum videolan car je sais que le sujet du DMB a été abordé dès 2004.
Sur les conseils de Nicolas, j'ai enregistré quelques flux T-DMB sur mon PC
avec une DRBOX1 et WinDAB. Pour ce récepteur DAB ancienne génération qui
ignore tout du DMB, ces flux sont vus comme des data stream et peuvent
effectivement être sauvegardés tels quels sur un ordinateur. La vitesse de
download des fichiers sous Firefox correspond effectivement au débit des
subchannels. Donc jusque là, rien de déconnant. Par contre, l'encodage Reed
Solomon qui a été ajouté en DMB et qui n'existait pas en DAB, la DRBOX le
traite comment ?
Salut,
la DR-BOX 1 n'a pas à traiter le reed solomon, c'est au player en aval
de le traiter.
Le flux que tu récupères grâce à la DR-BOX 1 est un TS204 avec l'octet
de synchronisation 0x47 comme indiqué dans la TS102427. Si tu fais une
rechercher sur cet octet avec un éditeurs hexa tu le retrouveras bien
tous les 204 octets.
Le problème, c'est d'essayer de récupérer quelque chose de ces fichiers par
la suite (qui ont l'extension .mpg)
Comme dit, précédemment, rien à faire avec VLC, les fichiers sont
illisibles. Le soft ne plante pas mais il ne décode rien du tout.
Idem avec Nero Showtime qui lui plante carrément.
J'ai essayé de passer ces fichiers dans un démultiplexeur MPEG TS, (TS
Reader, EMUX Pro), là encore TS Reader m'indique près d'une cinquantaine de
PID dans le flux (DSS Packet) avec des débits qui semblent tous faux et Emux
Pro refuse carrément d'ouvrir les fichiers quand il ne plante pas !
Tous ces produits ne savent pas décoder la couche SL. Par contre tu peux
toujours leur envoyer quelques flux pour qu'ils améliorent leurs
produits ;-)
Une rapide recherche sur Google montre qu'il n'existe aucun player DMB sur
PC en téléchargement... Eventuellement, quelques pages sur des sites tous
Coréens, mais vu qu'on ne comprend rien....
Bref, y a t-il une solution pour au moins démultiplexer ces fichiers et en
récupérer l'audio et la vidéo ?
Il faut modifier videolan pour qu'il puisse interpréter la couche SL, je
sais que certains ont essayé de le faire car ils sont arrivés à avoir au
moins une image. Je ne sais pas si le travail effectué a déjà été
commité dans les sources videolan, par contre tu peux éventuellement
trouver de l'aide sur le forum videolan car je sais que le sujet du DMB
a été abordé dès 2004.
Sur les conseils de Nicolas, j'ai enregistré quelques flux T-DMB sur mon PC avec une DRBOX1 et WinDAB. Pour ce récepteur DAB ancienne génération qui ignore tout du DMB, ces flux sont vus comme des data stream et peuvent effectivement être sauvegardés tels quels sur un ordinateur. La vitesse de download des fichiers sous Firefox correspond effectivement au débit des subchannels. Donc jusque là, rien de déconnant. Par contre, l'encodage Reed Solomon qui a été ajouté en DMB et qui n'existait pas en DAB, la DRBOX le traite comment ?
Salut,
la DR-BOX 1 n'a pas à traiter le reed solomon, c'est au player en aval de le traiter.
Le flux que tu récupères grâce à la DR-BOX 1 est un TS204 avec l'octet de synchronisation 0x47 comme indiqué dans la TS102427. Si tu fais une rechercher sur cet octet avec un éditeurs hexa tu le retrouveras bien tous les 204 octets.
Le problème, c'est d'essayer de récupérer quelque chose de ces fichiers par la suite (qui ont l'extension .mpg)
Comme dit, précédemment, rien à faire avec VLC, les fichiers sont illisibles. Le soft ne plante pas mais il ne décode rien du tout. Idem avec Nero Showtime qui lui plante carrément. J'ai essayé de passer ces fichiers dans un démultiplexeur MPEG TS, (TS Reader, EMUX Pro), là encore TS Reader m'indique près d'une cinquantaine de PID dans le flux (DSS Packet) avec des débits qui semblent tous faux et Emux Pro refuse carrément d'ouvrir les fichiers quand il ne plante pas !
Tous ces produits ne savent pas décoder la couche SL. Par contre tu peux toujours leur envoyer quelques flux pour qu'ils améliorent leurs produits ;-)
Une rapide recherche sur Google montre qu'il n'existe aucun player DMB sur PC en téléchargement... Eventuellement, quelques pages sur des sites tous Coréens, mais vu qu'on ne comprend rien....
Bref, y a t-il une solution pour au moins démultiplexer ces fichiers et en récupérer l'audio et la vidéo ?
Il faut modifier videolan pour qu'il puisse interpréter la couche SL, je sais que certains ont essayé de le faire car ils sont arrivés à avoir au moins une image. Je ne sais pas si le travail effectué a déjà été commité dans les sources videolan, par contre tu peux éventuellement trouver de l'aide sur le forum videolan car je sais que le sujet du DMB a été abordé dès 2004.
Un autre code "nouvelle" sur dab à été ajouté: dab+
http://tech.groups.yahoo.com/group/dabusb/
c'est des variantes, ca plait les programmeurs ?
-- -- Shortwave transmissions in English, Francais, Nederlands, Deutsch, Suid-Afrikaans, Chinese, Dansk, Urdu, Cantonese, Greek, Spanish, Portuguese, ... http://shortwave.homelinux.org Updated every month or so .... Digital TV in Europe: http://dvbt.homelinux.org
Un autre code "nouvelle" sur dab à été ajouté: dab+
http://tech.groups.yahoo.com/group/dabusb/
c'est des variantes, ca plait les programmeurs ?
--
--
Shortwave transmissions in English, Francais, Nederlands, Deutsch,
Suid-Afrikaans, Chinese, Dansk, Urdu, Cantonese, Greek, Spanish,
Portuguese, ...
http://shortwave.homelinux.org Updated every month or so ....
Digital TV in Europe: http://dvbt.homelinux.org
Un autre code "nouvelle" sur dab à été ajouté: dab+
http://tech.groups.yahoo.com/group/dabusb/
c'est des variantes, ca plait les programmeurs ?
-- -- Shortwave transmissions in English, Francais, Nederlands, Deutsch, Suid-Afrikaans, Chinese, Dansk, Urdu, Cantonese, Greek, Spanish, Portuguese, ... http://shortwave.homelinux.org Updated every month or so .... Digital TV in Europe: http://dvbt.homelinux.org
Zeldus
Salut Nicolas,
Merci pour tes infos. Si je comprends bien, en plus des données ajoutées par le MPEG2 TS, il y a aussi les données de protection Reed Solomon qui grignottent le débit utile des subchannels ? Je me rends pas vraiment compte combien ça représente, mais par rapport à ce qu'avait dit Olivier, je pensais que le débit des subchannels s'entendait hors codage RS et convolutif... En TNT, tous les récepteurs pour PC décodent les flux TNT en traitant le codage RS en hardware non ? (ou au moins au niveau du driver). Idem pour les CD pour lesquels ont a pas accès aux codes RS qui sont gérés directement par les lecteurs en hardware... Je pense que c'est parce que le codage RS a été ajouté après la définition de la norme DAB, ça fait quand même un peu bricolage je trouve mais bon, techniquement, ça rend le système encore plus intéressant et instructif ! Et pour le codage convolutif, vu qu'il y était avant avec le DAB, lui est traité par la DRBOX en natif ?
Sinon, il est clair que vu l'avenir du DMB, il serait bien qu'on ait au moins 1 ou 2 player sur PC et Mac qui puisse traiter ces flux car là, à part le B20 de iRiver, y a pas grand chose pour écouter la radio numérique !
Bonne journée
Pierre
Salut Nicolas,
Merci pour tes infos. Si je comprends bien, en plus des données ajoutées par
le MPEG2 TS, il y a aussi les données de protection Reed Solomon qui
grignottent le débit utile des subchannels ? Je me rends pas vraiment compte
combien ça représente, mais par rapport à ce qu'avait dit Olivier, je
pensais que le débit des subchannels s'entendait hors codage RS et
convolutif... En TNT, tous les récepteurs pour PC décodent les flux TNT en
traitant le codage RS en hardware non ? (ou au moins au niveau du driver).
Idem pour les CD pour lesquels ont a pas accès aux codes RS qui sont gérés
directement par les lecteurs en hardware... Je pense que c'est parce que le
codage RS a été ajouté après la définition de la norme DAB, ça fait quand
même un peu bricolage je trouve mais bon, techniquement, ça rend le système
encore plus intéressant et instructif ! Et pour le codage convolutif, vu
qu'il y était avant avec le DAB, lui est traité par la DRBOX en natif ?
Sinon, il est clair que vu l'avenir du DMB, il serait bien qu'on ait au
moins 1 ou 2 player sur PC et Mac qui puisse traiter ces flux car là, à part
le B20 de iRiver, y a pas grand chose pour écouter la radio numérique !
Merci pour tes infos. Si je comprends bien, en plus des données ajoutées par le MPEG2 TS, il y a aussi les données de protection Reed Solomon qui grignottent le débit utile des subchannels ? Je me rends pas vraiment compte combien ça représente, mais par rapport à ce qu'avait dit Olivier, je pensais que le débit des subchannels s'entendait hors codage RS et convolutif... En TNT, tous les récepteurs pour PC décodent les flux TNT en traitant le codage RS en hardware non ? (ou au moins au niveau du driver). Idem pour les CD pour lesquels ont a pas accès aux codes RS qui sont gérés directement par les lecteurs en hardware... Je pense que c'est parce que le codage RS a été ajouté après la définition de la norme DAB, ça fait quand même un peu bricolage je trouve mais bon, techniquement, ça rend le système encore plus intéressant et instructif ! Et pour le codage convolutif, vu qu'il y était avant avec le DAB, lui est traité par la DRBOX en natif ?
Sinon, il est clair que vu l'avenir du DMB, il serait bien qu'on ait au moins 1 ou 2 player sur PC et Mac qui puisse traiter ces flux car là, à part le B20 de iRiver, y a pas grand chose pour écouter la radio numérique !
Bonne journée
Pierre
Nicolas Croiset
On Wed, 10 Sep 2008 12:27:12 +0200, "Zeldus" wrote:
Salut Nicolas,
Merci pour tes infos. Si je comprends bien, en plus des données ajoutées par le MPEG2 TS, il y a aussi les données de protection Reed Solomon qui grignottent le débit utile des subchannels ?
Salut,
dans un subchannel on transporte un flux TS204 avec le RS du TS. Sans le RS, c'est un TS188.
Ensuite, à l'intérieur de la couche DAB il y a également une protection propre.
Dans le cadre du DMB on cumule les deux protections, ce qui assure une protection encore meilleure.
Je me rends pas vraiment compte combien ça représente, mais par rapport à ce qu'avait dit Olivier, je pensais que le débit des subchannels s'entendait hors codage RS et convolutif... En TNT, tous les récepteurs pour PC décodent les flux TNT en traitant le codage RS en hardware non ? (ou au moins au niveau du driver).
Dans le cadre d'un récepteur DVB-T, quand celui-ci décode il recoit un TS204 et en hardware/software on le transforme et vérifie/corrige pour le mettre en TS188.
Dans le cadre du DMB, la puce DAB décode le subchannel puis passe le flux au décodeur MPEG-2TS qui fait le boulot complémentaire. Dans le cadre du soft, celui-ci peut le faire également car cela consomme pas beaucoup de ressources. D'ailleurs VLC le gère très bien et fait la désencapsulation TS204 -> TS188.
Idem pour les CD pour lesquels ont a pas accès aux codes RS qui sont gérés directement par les lecteurs en hardware... Je pense que c'est parce que le codage RS a été ajouté après la définition de la norme DAB, ça fait quand même un peu bricolage je trouve mais bon, techniquement, ça rend le système encore plus intéressant et instructif ! Et pour le codage convolutif, vu qu'il y était avant avec le DAB, lui est traité par la DRBOX en natif ?
Tout à fait.
Sinon, il est clair que vu l'avenir du DMB, il serait bien qu'on ait au moins 1 ou 2 player sur PC et Mac qui puisse traiter ces flux car là, à part le B20 de iRiver, y a pas grand chose pour écouter la radio numérique !
Il y a beaucoup d'autres récepteurs, mais ils sont plus difficile à avoir par le grand public.
A+
On Wed, 10 Sep 2008 12:27:12 +0200, "Zeldus" <no@email.com> wrote:
Salut Nicolas,
Merci pour tes infos. Si je comprends bien, en plus des données ajoutées par
le MPEG2 TS, il y a aussi les données de protection Reed Solomon qui
grignottent le débit utile des subchannels ?
Salut,
dans un subchannel on transporte un flux TS204 avec le RS du TS. Sans
le RS, c'est un TS188.
Ensuite, à l'intérieur de la couche DAB il y a également une
protection propre.
Dans le cadre du DMB on cumule les deux protections, ce qui assure une
protection encore meilleure.
Je me rends pas vraiment compte
combien ça représente, mais par rapport à ce qu'avait dit Olivier, je
pensais que le débit des subchannels s'entendait hors codage RS et
convolutif... En TNT, tous les récepteurs pour PC décodent les flux TNT en
traitant le codage RS en hardware non ? (ou au moins au niveau du driver).
Dans le cadre d'un récepteur DVB-T, quand celui-ci décode il recoit
un TS204 et en hardware/software on le transforme et vérifie/corrige
pour le mettre en TS188.
Dans le cadre du DMB, la puce DAB décode le subchannel puis passe le
flux au décodeur MPEG-2TS qui fait le boulot complémentaire. Dans le
cadre du soft, celui-ci peut le faire également car cela consomme pas
beaucoup de ressources. D'ailleurs VLC le gère très bien et fait la
désencapsulation TS204 -> TS188.
Idem pour les CD pour lesquels ont a pas accès aux codes RS qui sont gérés
directement par les lecteurs en hardware... Je pense que c'est parce que le
codage RS a été ajouté après la définition de la norme DAB, ça fait quand
même un peu bricolage je trouve mais bon, techniquement, ça rend le système
encore plus intéressant et instructif ! Et pour le codage convolutif, vu
qu'il y était avant avec le DAB, lui est traité par la DRBOX en natif ?
Tout à fait.
Sinon, il est clair que vu l'avenir du DMB, il serait bien qu'on ait au
moins 1 ou 2 player sur PC et Mac qui puisse traiter ces flux car là, à part
le B20 de iRiver, y a pas grand chose pour écouter la radio numérique !
Il y a beaucoup d'autres récepteurs, mais ils sont plus difficile à
avoir par le grand public.
On Wed, 10 Sep 2008 12:27:12 +0200, "Zeldus" wrote:
Salut Nicolas,
Merci pour tes infos. Si je comprends bien, en plus des données ajoutées par le MPEG2 TS, il y a aussi les données de protection Reed Solomon qui grignottent le débit utile des subchannels ?
Salut,
dans un subchannel on transporte un flux TS204 avec le RS du TS. Sans le RS, c'est un TS188.
Ensuite, à l'intérieur de la couche DAB il y a également une protection propre.
Dans le cadre du DMB on cumule les deux protections, ce qui assure une protection encore meilleure.
Je me rends pas vraiment compte combien ça représente, mais par rapport à ce qu'avait dit Olivier, je pensais que le débit des subchannels s'entendait hors codage RS et convolutif... En TNT, tous les récepteurs pour PC décodent les flux TNT en traitant le codage RS en hardware non ? (ou au moins au niveau du driver).
Dans le cadre d'un récepteur DVB-T, quand celui-ci décode il recoit un TS204 et en hardware/software on le transforme et vérifie/corrige pour le mettre en TS188.
Dans le cadre du DMB, la puce DAB décode le subchannel puis passe le flux au décodeur MPEG-2TS qui fait le boulot complémentaire. Dans le cadre du soft, celui-ci peut le faire également car cela consomme pas beaucoup de ressources. D'ailleurs VLC le gère très bien et fait la désencapsulation TS204 -> TS188.
Idem pour les CD pour lesquels ont a pas accès aux codes RS qui sont gérés directement par les lecteurs en hardware... Je pense que c'est parce que le codage RS a été ajouté après la définition de la norme DAB, ça fait quand même un peu bricolage je trouve mais bon, techniquement, ça rend le système encore plus intéressant et instructif ! Et pour le codage convolutif, vu qu'il y était avant avec le DAB, lui est traité par la DRBOX en natif ?
Tout à fait.
Sinon, il est clair que vu l'avenir du DMB, il serait bien qu'on ait au moins 1 ou 2 player sur PC et Mac qui puisse traiter ces flux car là, à part le B20 de iRiver, y a pas grand chose pour écouter la radio numérique !
Il y a beaucoup d'autres récepteurs, mais ils sont plus difficile à avoir par le grand public.
A+
Zeldus
Salut Nicolas,
J'ai lu sur plusieurs forums et sites de codecs audio que passé 64 kbits/sec, l'AAC+ V2 n'était pas intéressant et qu'il vallait mieux utiliser l'AAC "classique" qui offrait une meilleure transparence aux sons. Or, je constate que certaines radios sont à plus de 64 kbits/sec pour le flux audio, et du coup, que la qualité audio pourrait être meilleure si celles ci passaient en AAC au lieu de prendre le HE AAC v2 spécialement étudié pour les très bas débits.
Je notre d'ailleurs qu'Apple n'a jamais voulu adopter l'AAC+ V2 sur ses ipod, préférant conserver des flux de 128 kbits/sec en AAC, de qualité bien meilleure (en particulier sur iTunes). C'est vrai qu'entre de l'AAC+ V2 à 64 kbits/Sec et de l'AAC à 128 kbits/Sec, y a pas photo, le son est bien meilleur sur les ipods 128kilo. A partir du moment ou l'on ne fera pas de télé en France avec le T-DMB, pourquoi chercher à descendre aussi bas dans les débits audio puisqu'on pourrait sans problème proposer du 96 kbits/Sec, du 112 kbits/Sec ou même du 128 kbits/sec en AAC ?
Car on fait avant tout de la radio et il ne faudrait pas commettre l'erreur de brider l'audio pour caser plus de radios dans les multiplexes, puisque le T-DMB nécessite l'utilisation de vidéo, même à très bas débit. J'ai l'impression qu'on a un peu sacrifié l'audio pour le T-DMB (entre la vidéo à caser plus la couche transport qui consomme pas mal en fait).
Pierrot
Salut Nicolas,
J'ai lu sur plusieurs forums et sites de codecs audio que passé 64
kbits/sec, l'AAC+ V2 n'était pas intéressant et qu'il vallait mieux utiliser
l'AAC "classique" qui offrait une meilleure transparence aux sons. Or, je
constate que certaines radios sont à plus de 64 kbits/sec pour le flux
audio, et du coup, que la qualité audio pourrait être meilleure si celles ci
passaient en AAC au lieu de prendre le HE AAC v2 spécialement étudié pour
les très bas débits.
Je notre d'ailleurs qu'Apple n'a jamais voulu adopter l'AAC+ V2 sur ses
ipod, préférant conserver des flux de 128 kbits/sec en AAC, de qualité bien
meilleure (en particulier sur iTunes). C'est vrai qu'entre de l'AAC+ V2 à 64
kbits/Sec et de l'AAC à 128 kbits/Sec, y a pas photo, le son est bien
meilleur sur les ipods 128kilo. A partir du moment ou l'on ne fera pas de
télé en France avec le T-DMB, pourquoi chercher à descendre aussi bas dans
les débits audio puisqu'on pourrait sans problème proposer du 96 kbits/Sec,
du 112 kbits/Sec ou même du 128 kbits/sec en AAC ?
Car on fait avant tout de la radio et il ne faudrait pas commettre l'erreur
de brider l'audio pour caser plus de radios dans les multiplexes, puisque le
T-DMB nécessite l'utilisation de vidéo, même à très bas débit. J'ai
l'impression qu'on a un peu sacrifié l'audio pour le T-DMB (entre la vidéo à
caser plus la couche transport qui consomme pas mal en fait).
J'ai lu sur plusieurs forums et sites de codecs audio que passé 64 kbits/sec, l'AAC+ V2 n'était pas intéressant et qu'il vallait mieux utiliser l'AAC "classique" qui offrait une meilleure transparence aux sons. Or, je constate que certaines radios sont à plus de 64 kbits/sec pour le flux audio, et du coup, que la qualité audio pourrait être meilleure si celles ci passaient en AAC au lieu de prendre le HE AAC v2 spécialement étudié pour les très bas débits.
Je notre d'ailleurs qu'Apple n'a jamais voulu adopter l'AAC+ V2 sur ses ipod, préférant conserver des flux de 128 kbits/sec en AAC, de qualité bien meilleure (en particulier sur iTunes). C'est vrai qu'entre de l'AAC+ V2 à 64 kbits/Sec et de l'AAC à 128 kbits/Sec, y a pas photo, le son est bien meilleur sur les ipods 128kilo. A partir du moment ou l'on ne fera pas de télé en France avec le T-DMB, pourquoi chercher à descendre aussi bas dans les débits audio puisqu'on pourrait sans problème proposer du 96 kbits/Sec, du 112 kbits/Sec ou même du 128 kbits/sec en AAC ?
Car on fait avant tout de la radio et il ne faudrait pas commettre l'erreur de brider l'audio pour caser plus de radios dans les multiplexes, puisque le T-DMB nécessite l'utilisation de vidéo, même à très bas débit. J'ai l'impression qu'on a un peu sacrifié l'audio pour le T-DMB (entre la vidéo à caser plus la couche transport qui consomme pas mal en fait).
Pierrot
Nicolas Croiset
On Fri, 12 Sep 2008 11:44:25 +0200, "Zeldus" wrote:
Salut Nicolas,
J'ai lu sur plusieurs forums et sites de codecs audio que passé 64 kbits/sec, l'AAC+ V2 n'était pas intéressant et qu'il vallait mieux utiliser l'AAC "classique" qui offrait une meilleure transparence aux sons. Or, je constate que certaines radios sont à plus de 64 kbits/sec pour le flux audio, et du coup, que la qualité audio pourrait être meilleure si celles ci passaient en AAC au lieu de prendre le HE AAC v2 spécialement étudié pour les très bas débits.
Salut Pierrot,
lorsque l'on spécifie HE-AAC V2, cela veut dire que le décodeur / récepteur doit être capable de décoder de l'AAC-LC ou de l'AAC-LC+SBR ou de l'AAC-LC+SBR+PS.
Le choix ensuite d'un de ces 3 modes d'encodage se fait comme tu le précises en fonction du débit, de la fréquence d'échantillonnage et du nombre de canaux (mono ou stéréo).
Je notre d'ailleurs qu'Apple n'a jamais voulu adopter l'AAC+ V2 sur ses ipod, préférant conserver des flux de 128 kbits/sec en AAC, de qualité bien meilleure (en particulier sur iTunes). C'est vrai qu'entre de l'AAC+ V2 à 64 kbits/Sec et de l'AAC à 128 kbits/Sec, y a pas photo, le son est bien meilleur sur les ipods 128kilo. A partir du moment ou l'on ne fera pas de télé en France avec le T-DMB, pourquoi chercher à descendre aussi bas dans les débits audio puisqu'on pourrait sans problème proposer du 96 kbits/Sec, du 112 kbits/Sec ou même du 128 kbits/sec en AAC ?
La qualité résultante dépends : 1/ de la qualité d'encodage de l'encodeur 2/ de la qualité de décodage et d'interprétation dela norme
Le choix d'apple est surtout parce qu'ils ne voulaient pas payer des licences d'utilisation trop coûteuses afin d'augmenter les marges ;-)
A+
On Fri, 12 Sep 2008 11:44:25 +0200, "Zeldus" <no@email.com> wrote:
Salut Nicolas,
J'ai lu sur plusieurs forums et sites de codecs audio que passé 64
kbits/sec, l'AAC+ V2 n'était pas intéressant et qu'il vallait mieux utiliser
l'AAC "classique" qui offrait une meilleure transparence aux sons. Or, je
constate que certaines radios sont à plus de 64 kbits/sec pour le flux
audio, et du coup, que la qualité audio pourrait être meilleure si celles ci
passaient en AAC au lieu de prendre le HE AAC v2 spécialement étudié pour
les très bas débits.
Salut Pierrot,
lorsque l'on spécifie HE-AAC V2, cela veut dire que le décodeur /
récepteur doit être capable de décoder de l'AAC-LC ou de l'AAC-LC+SBR
ou de l'AAC-LC+SBR+PS.
Le choix ensuite d'un de ces 3 modes d'encodage se fait comme tu le
précises en fonction du débit, de la fréquence d'échantillonnage et du
nombre de canaux (mono ou stéréo).
Je notre d'ailleurs qu'Apple n'a jamais voulu adopter l'AAC+ V2 sur ses
ipod, préférant conserver des flux de 128 kbits/sec en AAC, de qualité bien
meilleure (en particulier sur iTunes). C'est vrai qu'entre de l'AAC+ V2 à 64
kbits/Sec et de l'AAC à 128 kbits/Sec, y a pas photo, le son est bien
meilleur sur les ipods 128kilo. A partir du moment ou l'on ne fera pas de
télé en France avec le T-DMB, pourquoi chercher à descendre aussi bas dans
les débits audio puisqu'on pourrait sans problème proposer du 96 kbits/Sec,
du 112 kbits/Sec ou même du 128 kbits/sec en AAC ?
La qualité résultante dépends :
1/ de la qualité d'encodage de l'encodeur
2/ de la qualité de décodage et d'interprétation dela norme
Le choix d'apple est surtout parce qu'ils ne voulaient pas payer des
licences d'utilisation trop coûteuses afin d'augmenter les marges ;-)
On Fri, 12 Sep 2008 11:44:25 +0200, "Zeldus" wrote:
Salut Nicolas,
J'ai lu sur plusieurs forums et sites de codecs audio que passé 64 kbits/sec, l'AAC+ V2 n'était pas intéressant et qu'il vallait mieux utiliser l'AAC "classique" qui offrait une meilleure transparence aux sons. Or, je constate que certaines radios sont à plus de 64 kbits/sec pour le flux audio, et du coup, que la qualité audio pourrait être meilleure si celles ci passaient en AAC au lieu de prendre le HE AAC v2 spécialement étudié pour les très bas débits.
Salut Pierrot,
lorsque l'on spécifie HE-AAC V2, cela veut dire que le décodeur / récepteur doit être capable de décoder de l'AAC-LC ou de l'AAC-LC+SBR ou de l'AAC-LC+SBR+PS.
Le choix ensuite d'un de ces 3 modes d'encodage se fait comme tu le précises en fonction du débit, de la fréquence d'échantillonnage et du nombre de canaux (mono ou stéréo).
Je notre d'ailleurs qu'Apple n'a jamais voulu adopter l'AAC+ V2 sur ses ipod, préférant conserver des flux de 128 kbits/sec en AAC, de qualité bien meilleure (en particulier sur iTunes). C'est vrai qu'entre de l'AAC+ V2 à 64 kbits/Sec et de l'AAC à 128 kbits/Sec, y a pas photo, le son est bien meilleur sur les ipods 128kilo. A partir du moment ou l'on ne fera pas de télé en France avec le T-DMB, pourquoi chercher à descendre aussi bas dans les débits audio puisqu'on pourrait sans problème proposer du 96 kbits/Sec, du 112 kbits/Sec ou même du 128 kbits/sec en AAC ?
La qualité résultante dépends : 1/ de la qualité d'encodage de l'encodeur 2/ de la qualité de décodage et d'interprétation dela norme
Le choix d'apple est surtout parce qu'ils ne voulaient pas payer des licences d'utilisation trop coûteuses afin d'augmenter les marges ;-)
A+
Zeldus
Et quelle est la différence entre l'AAC et le BSAC ?
C'est abandonné le BSAC ?
Merci pour tes infos
Pierrot
Et quelle est la différence entre l'AAC et le BSAC ?
