PetitZef a écrit:Bonjour,
Je te remercie de tes réponses. Mon manque de connaissances techniques ne me permet pas d'en saisir tous les termes. Cependant en simplifiant, je comprends
- que le timing repose sur l'heure (de diffusion)
- qu'il est possible par différence entre l'heure à un point donné et l'heure du début de déterminer le temps écoulé depuis le début de l'enregistrement,
- que l'information timing n'est disponible que selon un intervalle donné et pas pour tous les paquets
et qu'en conséquence l'information susceptible d'être apportée pour le temps depuis le début de l'enregistrement sera imprécise, voire (au moins un peu) erronée puisque basée sur une information qui n'est donnée que périodiquement.
C'est un bon résumé. Ceci dit, il faut relativiser car l'erreur de timing ne sera que de quelques dizaines de millisecondes
J'avais abordé un autre point. Des perturbations qui entrainent une multitude de très petits décalages sons. Dans la mesure où me semble t'il, avec RecTVEdit, chaque décalage n'est indiqué que s'il dépasse une certaine valeur, j'ai pu vérifier que sur des sauvegardes défectueuses, je ne voyais pas par l'analyse ces décrochages. J'ai pu les voir en analysant la bande son avec EAC3to. D'ailleurs dans ce cas, une tentative de conversion EAC3 vers AC3 échoue ou n'est pas correctement effectuée. Y aurait il la possibilité de disposer de cette information, même si par choix, tu as pris l'option de retenir un seuil pour délivrer cette information.
Si je mets les seuils trop bas, ce sont des milliers de messages qui risquent d'apparaître, sans que ce soit justifié
Et tu dois savoir qu'il y a toujours de légères variations dans la régularité des timings sans que ce soit anormal.
Ce que je pourrais faire, c'est créer un écran vous permettant d'ajuster tous les seuils utilisés, mais c'est un peu de boulot. Si je veux aller au plus simple, je les ajoute dans le fichier de préférences, ce qui permettra aux "experts" de les ajuster en éditant manuellement leur fichier de préférence.
Par contre reste le fait que selon mon observation, une multitude de très petits problèmes aurait une conséquence égale à un problème isolé plus grave, mais qui lui est signalé.... Peut être la règle consistant à ignorer dans l'analyse les écarts sur les "delay" lorsqu'ils sont faibles et isolés, pourrait mériter un rappel ou confirmation en fin d'analyse du type "Aucun décalage son observé" ... Il va de soi qu'une telle mention ne pourra intéresser que quelques personnes et la vocation de RecTVEdit est peut être de rester plutôt généraliste... Malgré tout si tu as la possibilté de répondre sur ce point, ça m'intéresse.
Conclure à un décalage son ou pas n'a rien d'évident pour moi. J'imagine que ça dépend de pas mal de paramètres, et que le résultat est même peut-être différent d'un lecteur à un autre.
Si ton but est de repérer des plus petits écarts que ceux définis par le seuil, je pourrais introduire un second seuil, fixé à une valeur plus faible (elle aussi ajustable dans le fichier des préférences), et me contenter de compter les cas où on se trouve entre les deux seuils pour le signaler en fin de rapport. Est-ce ce que tu recherches ?
Sinon,
As- tu toujours dans tes projets, une évolution permettant les coupures pub? ça parait tout de même très compliqué!!!
Plus vraiment, car je ne consacre désormais que peu de temps à faire évoluer le logiciel. Pire, je ne l'utilise même plus, ou super rarement !
Par ailleurs, il existe des logiciels plus spécialisés là-dedans qui font un bon boulot, non ?
Quel intérêt peux-tu porter à une conversion EAC3 vers AC3?
C'est une idée que j'ai également abandonnée car il faudrait s'appuyer sur un convertisseur (comme eac3to) et un remuxer (comme TsMuxer) et je sais que tout ça n'est pas hyper fiable dès lors que le fichier source n'est pas "propre".
Par ailleurs, des logiciels de conversion audio/vidéo, il en existe des centaines.
Aujourd'hui, je me contente de répondre positivement à ceux qui me demandent des évolutions, dans la mesure où ça peut être fait relativement simplement.
