Reprise du message précédent :
ça le fait avec d'autres versions de transcode ?
ta piste audio est bien la 0 ?
 
Vois vraiment pas...

 
A mon avis ça vient de ton CVS de transcode.

1)oui c'est possible et c'est très simple avec les ogmtools...
 
2)pour ne ripper qu'un chapitre :  
 

 
ça rippe le chapitre $chap et la piste son $index et ça calcule à la volée le volume rescale pour la normalisation.
 
3)Pour ne pas voir les infos libdvdcss : aucune idée mais je suis preneur si qqn trouve.
 
4)Pour l'index par défaut dans mplayer : probablement 0, à vérifier...

ma ligne de commande te sort un vob du chapitre voulu avec la vidéo et une piste son...

et en rc2 ?
Jamais constaté ça...

 
Pour la première question, oui (avec -s devant le stream son pour la synchro)
 
Pour la seconde je sais pas. MPlayer a son propre format de sub, c'est peut-être celui là qui est mentionné dans cette liste.
En tout cas il relit les .sub avec la méthode que j'ai indiquée dans la doc.
 
A part ça j'ai fait des tests d'encodage avec la nouvelle option permettant de diminuer et bloquer les quantizers sur le générique (en fait une plage de frames) et ça marche au poil.

 
Bien sûr ! D'ailleurs jotenakis est en train de le mettre en place pour la prochaine version du script.
Pour l'instant avec la version 0.60, c'est simple :
1) Détermine la plage à bloquer en frames. Pour ça tu lis le dvd (ou le vob) jusqu'au début du générique et tu notes le temps en secondes et tu multiplies par 25 (PAL) ou 29.97 (NTSC). Soit tu le lis sur la console, soit tu utilises l'osd de mplayer (mais tu dois compiler mplayer avec ./configure --enable-freetype et faire un simlink vers une fonte ttf de ton choix, vois le paragraphe 1.4.2 du manuel)
2) Tu mets par exemple dans le fichier de prefs .tuxriprc :

 
C'est bien sûr vrc_override le paramètre clef :
132775,136575,20-31 = de la frame 132775 à 136575 (c'est pas grave si la seconde dépasse la fin exacte) et bloque les quantizers de 20 à 31. C'est répété deux fois à l'identique pour le 1st et le 2nd pass.
Tu peux bloquer 31-31 par exemple mais là la qualité est extrêmement diminuée (impossible de lire le texte défilant du générique).
 
Je te l'ai indiqué pour libavcodec, tu as la description des options pour xvid dans man mplayer.

Je viens de m'apercevoir que je t'ai dit une connerie pour les sous-titres : tu mentionnais les formats supportés par ogmmerge. Je ne sais pas du tout le format de sous-titre à mettre dans un stream ogg, désolé. Mais ça n'indiquait pas le format mplayer dans ce cas...

 
Sous Win ? T'as installé les filtres OggDS ?

 
Si je comprends bien, sous Win il lit quand il y a un seul stream audio, mais pas plus. Et sous nux ?
Ca vient peut-etre d'un bug des oggDS ? Il faudrait voir. Ils ont une mailing list ?

 
comprends pas
Essaie de rajouter les streams audio 1 par 1 comme dans la doc :
ogmmerge  -o  MM-complete.ogm  MyMovie-with-sound.ogm  MyMovie-add-audio.ogg

 
Si si je suis aussi en rc2, et ça l'est depuis la cvs suivant la rc1.
C'est sous les options  
-lavcopts <option1:option2:...>
 
vrc_override=<options>
                                     User specified quality for specific parts
                                     (pass 1/2).   The  options  are   <start-
                                     frame,  end-frame,  quality[/start-frame,
                                     end-frame, quality[/...]]>:
                                        quality 2-31: quantizer
                                        quality -500-0: quality correcture  in
                                        %

 
En effet, je le retrouve pas. Faut attendre que l'option soit implémentée alors. Tu préfères xvid question résultat ?

pour ma part, après les tests que j'ai fait pendant les vacances je préfére lavc qui est 20% plus rapide et de qualité un peu meilleure.
 
Mais c'est quand même très proche. En revanche l'utilisation de l'option "spéciale générique" dispo pour le moment seulement en lavc redonnera un avantage significatif en qualité à lavc.
 

 
J'étais persuadé que ça existait pour xvid dans mencoder (d'autant que le codec de Koepi sous win a cette option). J'ai dû rêver ?

me semble que ça existe dans xvid-transcode mais pas encore dans xvid-mencoder.

 
ah ouais, à force, j'ai mélangé les deux !
Je pense que ça finira par venir avec mencoder de toute façon. Il faut dire qu'ils ont ajouté xvid bien après libavc.

 
A partir de quel longueur de film est-il suggérer de créer un fichier de 2 X 700 Mo (2 CDs) plutôt qu'une fois ?
 
C'est une vrai question mais ça relance aussi le topic.

 
Ca depend. Si ton film est plutot Bergman, je dirais 2h. Si c'est plutot Jean-Claude Van Damme versus Independence Harbour in the Two Towers ce serait 1h15.
J'ai fait de tres bons encodages de films d'1h45 sur 1 seul CD, mais pour Gladiator c'etait sur 2.
 
Aussi ca va dependre de tes options, si ton film est plutot sombre ou clair. Par exemple, le lumi_masking permet de comprimer d'avantage les zones sombres, donc cette option peut etre interessante pour un film comme Final Fantasy. Mais a utiliser avec prudence.
 
Ca depend egalement de la resolution finale : un film sur 4/3 comme Eyes wide shut necessitera plus de bits qu'un cinemascope ou tu coupes les bandes noires.
Comme regle de base : je vise d'abord 1CD avec un CQ de 0.22, et je vois si je suis au dessus de 700-800kbps. Sinon, je prends 2 CD et un CQ de 0.27.

 
C'est encore tres experimental, perso je ne les utilise pas. J'avais essaye une fois mais j'avais des carrés gris dans les zones noires. J'ai abandonné, mais ça fait plus de 6 mois, donc je suppose que ça vaudrait le coup de refaire une tentative.
Ils permettent de comprimer davantage des zones sombres ou claires unies. Ca peut être intéressant pour un film comme "les autres" ou "alien" par exemple où on est très souvent dans le noir.
 
Je ne connais que le lumi masking de xvid, qui est pour le noir. Pour libavc, apparemment il y a deux masques pour le dark et le lumi. Il faut faire des essais mais ça peut être intéressant.

Merci, je suis enfin fixé sur le sujet.

 
Si tu utilises le script, il t'indiquera le bitrate après cropping, et là tu peux décider de changer pour 2 CDs.

Pour l'instant j'utilise k3b, mais il faudrait que j'essaye de faire tourner ce tuxrip. J'avais eu quelques bugs suite à des dépendances non satisfaites et j'avais pas trop approfondi.

 
k3b c'est pour graver.
T'as quelle distro ?

[edit]Mandrake 9.0. Le post du dessus n'était pas encore apparu. k3b possède un excellent frontend de transcode qui permet de ripper et encoder un DVD en DivX ;-). Perso c'est ce que j'utilise.[/edit]
 
J'ai pas envie d'abuser mais ça me dirait tout de même de faire la lumière sur certains points que vous avez l'air de connaître si bien. Une fois que cela sera mon cas, je me lancerai dans Tuxrip.
Tous les howtos et sites prétendus dire des choses ne m'ont pas grandement aidé.
 
J'ai pas très bien compris cette histoire de CQ... Est-ce que cela tient compte du fait que l'on veuille voir le film en plein écran ? Je n'en tenais même pas comtpe de ce CQ avant, c'est tout dire, pourtant il est affiché dans k3b.
Je m'explique :
Mon présent projet est un film de 1h20. Je séléctionne alors 1X700 Mo => Bitrate = 1108 kbits.
Dans les paramètres avancés, je peux croper. Il n'y a pas d'aussi grandes bandes noires que d'habitude. (8 px en haut et 11 en bas). Ca me donne une vidéo de 720 X 405 mais un CQ de 0,15. Si je titille la barre du recadrage, je peux arriver à un CQ de 0,22 (cf post ci-dessus) pour une taille de 592 X 352.
Etant donné que je veux regarder le film en plein écran la meilleure qualité me sera rendue en laissant la taille quasi telle quelle avec un CQ de 0,15 ou en resizant jusqu'à 592 X 352 pour avoir un CQ de 0,22 ???
C'est la grosse question que je me pose.
En gros : Ce CQ détermine la qualité, alors comment un fichier plus petit (592 X 352) pourrait en avoir une meilleure ?
 
Je sais pas si vous m'avez compris mais je vous remercie d'avance pour votre aide.

 
Il faut que tu lises au moins le manuel de tuxrip en première page de ce thread, on a tout mis : notamment la partie "encodage manuel" car on détaille toutes les étapes et notamment le CQ. Je rajouterai les explications sur le CQ dans la FAQ par contre.
 
Donc pour résumer : le CQ représente le nombre de bits à utiliser pour encoder par pixel et par frame. En gros, plus ton CQ est élevé, moins tu verras d'artefacts de compression. Mais ton nombre de bits est lui fini. Donc tu choisis entre une grande image mais peu de bits par pixel pour l'encoder, ou un peu plus petite et plus de bits par pixel.
Un peu comme une image statique en jpeg : tu peux compresser d'avantage pour diminuer la taille finale, mais en revanche si tu compresses trop, tu auras des artefacts de compression, notamment des carrés unis au niveau des aplats de couleur. Donc tu peux réduire la taille finale de ton image pour réserver d'avantage de bits à chaque pixel pour éviter cette perte.
 
C'est exactement la même chose avec le CQ. Si tu descends en-dessous de 0.18, ton image est en général très dégradée, car il n'y a pas assez de pixels pour encoder avec suffisamment de détail l'image (en mpeg4, l'image est découpée en carrés (blocs) plus ou moins gros et ces carrés sont compressés). Il en résulte une image très "blockie" : on voit beaucoup ces blocs à l'intérieur de l'image.
En revanche, au-dessus de 0.20 il y a suffisamment de bits pour compresser les blocs, la frontière entre les blocs s'atténue et est presque invisible.
C'est pour ça qu'il vaut mieux réduire la taille de l'image pour avoir un CQ assez élevé et éviter qu'on voie les blocs. Un DivX en 720 de large sera généralement moins bon que le même en 600 ou moins pour cette raison.
Le CQ est indicatif : tu peux descendre parfois jusqu'à 0.18 pour du Bergman, mais pas pour Matrix. En revanche, il est inutile d'aller au-dessus de 0.30, de la même façon qu'une image jpeg compressée en 0.75 a quasiment le même aspect qu'une image jpeg en 0.95 : l'oeil humain n'est plus capable de discerner la perte de détail.

J'avais lu pourtant. Cela me semble bien plus clair comme tu viens de me l'expliquer.
Merci.

 
C'était pas un reproche, plus un conseil. C'est possible qu'on l'ait détaillé dans l'ancien topic et moins dans celui-là.
Ca me donne une bonne raison pour l'ajouter bientôt dans la FAQ
 
Sinon je viens de regarder k3b, c'est pas mal en effet, très similaire à Gordian Knot sous Win. Par contre transcode encode moins vite que mencoder, et tuxrip a plein de petits trucs pratiques : mode resume, encodage ogg vorbis qui non seulement a une meilleure qualité mais permettra plusieurs streams : audio et sous-titres, synchro son, extinction à la fin de l'encodage, gestion des options dans un fichier de pref, support de l'encodage réduit du générique, etc...
Et la gravure sera bientôt implémentée.

 
Le manuel est là http://www.gnu.org/manual/bc/index.html
Je ne l'ai pas encore lu, et j'en ai besoin aussi.

Tu saurais quelle fonction utiliser en bash pour prendre l'entier le plus proche d'un nombre décimal (ou le résultat d'une opération) ?

 
Le problème de scale=0 est qu'il supprime les décimales. Donc 1.9  est 1 et moi je veux l'entier le plus proche.

pour obtenir l'entier le plus proche avec bc, il faut ecrire une petite fonction, car elle n'existe pas par defaut :
 

 
resultats :  
1.3 -> 1
1.8 -> 2
-1.8 -> -2
-1.1 -> -1
1.5 -> 2
-1.499999999 -> -1
 

en passant j'ai une chtite question :
 
ton script est ecrit en bash ou il marche aussi sous ksh csh etc ?
 
parce que  
1- il vaudrait mieux mettre #!/bin/bash en en-tete dans ce cas (sous mandrake, par defaut, sh = bash mais c'est pas toujours vrai)
2- ca serait pratique de savoir ca pour les tests de presence des application mplayer, mencoder, etc...
 
Sinon, justement a propos de ce test de presence, j'aimerais bien en faire une version alors je voulais savoir ce que tu esperais faire :
- tester uniquement la presence des executables dans le path ?
- tester la presence des executables n'importe ou sur le disque, avec une possibilité de mettre des chemins differents (genre, on execute pas "mplayer" mais la variable $MPLAYER qui contient le chemin réél de l'appli)
- tester la version des executables si ceux-ci sont présents, auquel cas il faudrait connaitre les versions minimales à utiliser avec tuxrip...
 
Je connais pas grand chose aux encodages video, mais le reste de la prog, je peux aider, alors je me propose

  je regarde ça.

   
Je connais pas trop les différences alors je suppose que c'est du bash, je changerais l'en-tête. Tu as raison.
 
Je pensais juste testé dans le path mais on peut éventuellement faire mieux. Si tu veux t'y coller, ça serait avec plaisir.
 
Pendant que j'y suis, j'aimerais un test pour savoir si une variable est un nombre réel. J'ai ce qu'il faut pour un entier mais pas pour un réel. Tu saurais ? genre ça refuse 1.3.1 mais accepte 1.31 ou -1.31 ou 1.0 ou 1 ...

 
Je devrais avoir un peu de temps a partir de ce soir, congé paternité powaaaa plus qu'a esperer que le petit dorme un peu cette nuit
 

 
Je regarderai aussi ce soir

 
Excellent. Il y a aussi une autre regle :
- pour un nombre positif, l'entier le plus proche est la partie entiere de (ce nombre + 0.5)
- pour un nombre negatif, c'est celle de (ce nombre - 0.5)

SORTIE DU SCRIPT tuxrip065.
Changement :
             * correction dans le calcul du ratio
             * support de l'encodage des génériques (nécéssite la compilation de mplayer avec support de l'OSD)
             * ajout d'une prévisualisation avant encodage. (il faut relancer tuxrip en mode --config pour choisir le programme de visualisation)
             * support des DVD possédant des bandes son en MPEG (géré automatiquement).
 
 

@ zeb_ : c'est a peu pres cette regle que j'ai codée oki c'est pas forcement clair, mais c'est ca

 

 
Bon je vais ajouter les explications en première page pour compiler mplayer avec l'OSD.