L'Encodage : les codecs

barz13 · Message par **barz13** » 16 mai 2011 10:12

Moi perso c' est mp3 320kbps et FLAC mais bon j' ai déja testé une meme piste en 320 et en FLAC et j' ai jamais entendu une différence. A ce qu' il parait le FLAC est plus utile aux amateurs de musique Metal, moi je me sers du FLAC souvent pour de la Soul, mais ptete que c' est de la parano et que le mp3 320 irait trés bien...

Parpadello · Message par **Parpadello** » 16 mai 2011 11:50

barz13 a écrit :Moi perso c' est mp3 320kbps et FLAC mais bon j' ai déja testé une meme piste en 320 et en FLAC et j' ai jamais entendu une différence. A ce qu' il parait le FLAC est plus utile aux amateurs de musique Metal, moi je me sers du FLAC souvent pour de la Soul, mais ptete que c' est de la parano et que le mp3 320 irait trés bien...

Honnêtement, j'ai testé les 2 pour du metal assez rapide, et dans un environnement "nomade" (transports/bureau/parc), je n'ai pas discerné de différences entre du FLAC et du Vbr 0.

Après pour le sédentaire, je reste sur du lossless, mais y'a pas un bruit au moins autour de moi

Sby' · Message par **Sby'** » 07 juil. 2011 00:31

je m’ennuyais alors j'ai fais un petit screenshot et un petit montage de courbe
Le mp3 est obtenue avec dvpoweramp qui est le meilleur convertisseur (lame) je lui ai demandé de me faire un mp3 le plus fidèle possible du flac. Et les résultat sont impressionnant:

des differences surtout dans les hautes fréquences.

le comparatif final:

sur cette image on voit que le flac est légèrement plus dynamique que le mp3 320 cbr

le schéma est pas si bien que ça, on ne voit que les rajout par rapport au mp3 128 et non les trous.
j'ai pas trouvé d'autre méthode qui permettait de bien voir les courbes mais en les superposant.

Antoine · Message par **Antoine** » 18 oct. 2011 12:38

Le codec LAME est disponible en version 3.99 finale depuis quelques jours :

http://lame.sourceforge.net/

Parpadello · Message par **Parpadello** » 18 oct. 2011 16:54

Antoine a écrit :Le codec LAME est disponible en version 3.99 finale depuis quelques jours :

http://lame.sourceforge.net/

Un petit coup de pub pour XLD sur Mac, qui depuis le 16 octobre intègre cette version

Tutut · Message par **Tutut** » 18 oct. 2011 17:23

Le Changelog (je vais attendre tranquillement qu'il soit packagé pour ma distribution) :

LAME 3.99 October 15 2011

3.99 beta 1 becomes 3.99

LAME 3.99 beta 1 not yet released

Robert Hegemann
Fix for Bugtracker item [ 3395813 ] id3tag_set_fieldvalue for URL link frames Broken
Fix for Bugtracker item [ 3368977 ] Wave Parser doesn't pad chunks
Fix for Bugtracker item [ 3034259 ] confusing fatal error: can't update LAME-tag frame!

LAME 3.99 beta 0 not officially released

Josep Maria Antolín Segura
Documentation work
Rogério Brito
Improve Debian packaging.
Include suggestions made by Fabian Greffrat
Update version of the Debian package to reflect that it is taken from CVS.
Get rid of a transitional package
Much more to come...
Minor fix to validate the history file correctly
Robert Hegemann
Porting of LAME mp3rtp program to Windows platform
Fix: for free format mp3 above 320 kbps, the maximum allowed bits was limited too far.
Changed behaviour: LAME replaces common suffixes by MP3/WAV when no output filename was given. For example, a simple lame x.wav will create output file x.mp3
UNICODE support on Windows OS, file names and ID3v2 tags; related: Bugtracker item [ 3052230 ] Lame.exe can't find files with non-ASCII names
Added support for WAVE FORMAT IEEE FLOAT input files
New switch --swap-channel added, see tracker item [ 1118412 ] RFE: option to swap L and R channels
New switches -m l and -m r to select either left or right channel for mono encoding.
Feature request item [ 3134258 ] Allow larger images with LAME (>128KB)
Fix for Bugtracker item [ 2962223 ] Encoder delay and padding values ignored when re-encoding
Fix for Bugtracker item [ 2986823 ] Error when building Lame with NASM support -still exists
Fix for Bugtracker item [ 3125235 ] make -f Makefile.mingw32 fails
Fix for Bugtracker item [ 3021935 ] ID3 tag TXXX cannot be used more than once
Fix for Bugtracker item [ 3025801 ] gain_analysis.h needs int constants
Fix for Bugtracker item [ 3277412 ] Segmentation fault at layer2.c:105 with --decode
Changes in new VBR code:
tuning on PSY model
tuning on VBR scale and resulting bitrates
Minor bug fix for sfb21 encoding
All encoding modes use the PSY model from new VBR code, addresses Bugtracker item [ 3187397 ] Strange compression behavior
Fix for a possible out of bounds array access in HIP decoder, addresses Bugtracker item [ 3091776 ] crash at III_dequantize_sample

lolosormiou · Message par **lolosormiou** » 19 oct. 2011 06:51

[quote="Tutut"]Le Changelog (je vais attendre tranquillement qu'il soit packagé pour ma distribution) :

Tu tournes sur GNU/Linux ?
j'suis sur Arch

Perso je l'ai pas encore mais je suis pas en testing non plus.

Olivier · Message par **Olivier** » 19 oct. 2011 09:07

Merci pour l'info, je vais compiler les sources pour OS X Lion. Si ça intéresse quelqu'un...

Tutut · Message par **Tutut** » 19 oct. 2011 15:29

lolosormiou a écrit :Tu tournes sur GNU/Linux ?
j'suis sur Arch
Perso je l'ai pas encore mais je suis pas en testing non plus.

Je ne suis pas particulièrement à cheval sur l'appellation, pour moi c'est Linux avec ou sans gnou.

J'avais bien aimé Arch, essayé sur VirtualBox, par fainéantise je suis resté adorateur de la Grande Spirale (Debian testing).

TheDecline01 · Message par **TheDecline01** » 19 oct. 2011 18:23

Et une question sur la compression en soit : que fait-elle ?

Elle enlève les fréquences extrêmes du spectre ? Elle comprime le son pour lui donner moins d'amplitude ? Elle enlève carrément certains passages trop inaudibles (pas assez forts) ? Autre ?

Car je me suis toujours demandé ce qui se passait réellement derrière une compression. On perd des données, soit, mais quel type de données ?

Parpadello · Message par **Parpadello** » 07 janv. 2012 23:17

Vu que j'ai posté le lien par là, certains tomberont peut être sur ma question ici

Je me pose une question concernant l'AIFF et sa gestion dans iTunes : j'ai pris l'habitude d'afficher les débits dans celui ci. Pour tous mes morceaux en ALAC, il varie comme pourraient le faire des morceaux mp3 en VBR.

Or, lors des quelques conversions que j'ai faites pour tester l'AIFF, iTunes indique pour tous (hors ceux en 24/96) précisement 1411 kbits/s. A quoi c'est dû, même si c'est d'une importance relative ? J'ai le sentiment que c'est comme pour le mp3 et le CBR/VBR, mais j'ai plus de mal à me l'expliquer bizarrement vu qu'il n'y a pas de compression.

Basaltinou · Message par **Basaltinou** » 07 janv. 2012 23:41

C'est assez simple en fait.
Un master fait pour un CD, c'est 16 bits par échantillon et 44100 échantillons prélevés par seconde.
Et c'est ce qui utilisé par défaut pour l'AIFF ou le WAV.
De là, c'est de la multiplication bateau :
16 * 44100 = 705600 bits (donc 705,6 kbits) par seconde.

Il ne faut pas oublier qu'on a le canal droite et le canal gauche à encoder !
On a donc 705600 * 2 = 1411200 bits par seconde pour restituer un signal stéréo. On a donc bien 1411(,2 mais bon 200 bits c'est rien à côté, d'où l'arrondi) kbits par seconde.

Bigtonio · Message par **Bigtonio** » 07 janv. 2012 23:48

TheDecline01 a écrit :Et une question sur la compression en soit : que fait-elle ?

Elle enlève les fréquences extrêmes du spectre ? Elle comprime le son pour lui donner moins d'amplitude ? Elle enlève carrément certains passages trop inaudibles (pas assez forts) ? Autre ?

Car je me suis toujours demandé ce qui se passait réellement derrière une compression. On perd des données, soit, mais quel type de données ?

Bien expliqué ici

http://www.01audio-video.com/la_compression_mp3.htm

Parpadello · Message par **Parpadello** » 07 janv. 2012 23:54

Basaltinou a écrit :C'est assez simple en fait.
Un master fait pour un CD, c'est 16 bits par échantillon et 44100 échantillons prélevés par seconde.
Et c'est ce qui utilisé par défaut pour l'AIFF ou le WAV.
De là, c'est de la multiplication bateau :
16 * 44100 = 705600 bits (donc 705,6 kbits) par seconde.

Il ne faut pas oublier qu'on a le canal droite et le canal gauche à encoder !
On a donc 705600 * 2 = 1411200 bits par seconde pour restituer un signal stéréo. On a donc bien 1411(,2 mais bon 200 bits c'est rien à côté, d'où l'arrondi) kbits par seconde.

Merci beaucoup pour cette explication limpide et précise Basaltinou !

Tout est très clair : AIFF me voilà.

Basaltinou · Message par **Basaltinou** » 08 janv. 2012 00:04

Mais de rien

Et concernant l'ALAC, disons qu'on pourrait voir ça comme le "VBR" du WAV/AIFF : là où le VBR va chercher la bonne compression à appliquer en fonction du signal à ce moment là, l'ALAC et les formats lossless vont essayer de compresser de leur mieux certains bouts du signal (mais sans le modifier par contre).