Vous n'êtes pas identifié(e).
Bonjour,
Depuis quelques temps les durées des enregistrements sont complètement farfelues : une émission avait lieu de 21h00 à 21h59 > le MP3 durait 01h08:01... Une autre avait lieu de 20h00 à 21h59 > le MP durait 1h59:43... (j'avais déjà remarqué ça sur la version précédente mais ça se jouait à "seulement" une ou deux secondes près). (même problème avec la V.1.6 et la V.2)
Voici mes 1ers retours sur la V2 de WRT :
- le module permettant de savoir quels titres ont été le plus diffusés sur une période donnée a disparu ?! dommage
- Je n'ai pas testé les rapport Sacem, etc. n'ayant pas les identifiants sous la main, mais je regrette qu'il faille justement cet identifiant : un fichier *.TXT fournissant les logs de playlist jours par jour serait très intéressant pour les archives de la radio.
Merci pour le développement et les corrections.
Cordialement
Hors ligne
Bonsoir,
Les durées des MP3 ne sont pas stockées dans les fichiers audio, mais sont calculées en fonctions de leurs caractéristiques.
Il est possible que l'estimation qui en résulte ait une différence de quelques secondes avec l'horloge système, surtout au bout d'une ou deux heures.
Cependant, 8 minutes d'écart me semble excessif et ne s'explique probablement pas par un problème d'arrondi.
> A l'écoute du MP3, remarque-t-on un problème de durée (incomplet / trop long) ?
> Ceci se produit-il systématiquement ou occasionnellement ?
Il n'y a plus de statistiques sur les diffusions en effet car les logiciels de diffusion doivent garantir une répartition adaptée des titres en playlist.
Les rapports SACEM, SCPP & SPPF sont accompagnés d'identifiants : qu'importe l'identifiant en question, du moment qu'il comporte 3 caractères pour la SACEM et 6 caractères pour SCPP & SPPF, cela ne gènera pas la génération du rapport. Ceci dit, ces rapports ne sont pas exploitables par les webradios.
La playlist jour par jour est stockée dans l'historique lequel peut être exploité par une base de données.
Pourquoi pas une option pour stocker ceci jour par jour dans un répertoire dédié.
A voir.
Hors ligne
Test d'enregistrement réalisé sur une durée d'1h00 : aucun problème remarqué (l'enregistrement indique une durée de 59:59).
L'horloge est-elle bien stable ? (j'ai déjà vu des pc où l'horloge devait être régulièrement mise à l'heure)
Le pc est-il en overclocking ?
Hors ligne
L'erreur de 8 mn a été exceptionnelle.
toutefois il n'est pas rare qu'il manque plusieurs secondes à une émission (l'enregistrement d'une émission d'une heure de ce soir fait 59mn et 51 secondes...) (j'ai fait le test avec la version de WRT d'avril 2010, réinstallée aujourd'hui).
Dimanche, avec la V2, une émission de 2h faisait 119 mn et 43 secondes...
Depuis quelques semaines, cela se produit à chaque.
L'horloge est bien stable (nous avons une horloge dans le studio qui est réglée à la même heure) et le PC n'a pas été overclocké.
Concernant les statistiques de diffusion, je trouve cela très dommage de l'avoir enlevé : les logiciels de diffusion (hors ceux pour les grosses radios) ne sont pas forcément toujours très précis et l'outil de stats nous étaient très précieux.
Merci.
Hors ligne
Si le problème ne survient que depuis quelques temps, il n'est probablement pas lié directement à l'application je pense.
Si vous constatez que l'enregistrement démarre et se termine bien aux heures indiquées il n'y a pas de raison que le fichier change de taille ensuite.
Au sujet des statistiques de diffusion, cela est à voir pour les prochaines semaines / prochains mois, dès lors que j'aurai à nouveau le temps suffisant pour me consacrer au développement de l'application.
Hors ligne
Quels sont les paramètres d'enregistrement audio ? (fréquence / taux d'échantillonnage....)
Faites un test en les modifiant.
Hors ligne
Jusqu'à hier j'enregistrais en MP3 192k / 44,1 kHz. Je suis passé en 160k / 44,1 kHz cet après-midi. Et même résultat. Je testerai demain dans une autre qualité.
Hors ligne
Je viens de faire le test sur un enregistrement de 6 heures et 1 minute à 48 KHz, 320 kbits/s.
Le fichier est marqué : création à 00:00:00 dernière modification à 06:01:00.
La durée indiquée est de 06:03:26 : il s'agit donc bien d'une erreur de calcul de la durée.
Je me laisse penser que ceci est dû à l'encodeur MP3 pour lequel je force l'encodage à un bitrate constant (indispensable pour pouvoir l'utiliser directement avec un serveur Shoutcast comme intro / bande de secours).
Pouvez-vous m'indiquer si, quand vous écoutez le MP3 :
- votre émission est coupée avant terme
- si au contraire, l'enregistrement déborde après la fin de l'émission
- si la coupure se fait bien au top horaire ?
Hors ligne
Je suis en train de faire plusieurs séries de tests.
En 48 kHz, l'écart semble se réduire (de 0 à 2 secondes).
Je continue l'enquête et vous tiens au courant...
Sinon, à propos de la V2, les icônes du menu du haut sont très grosses pour un écran en 1024*768.
Hors ligne
Entendu. Je poursuis de mon côté également les recherches durant le temps dont je dispose.
Faites un clic droit sur les icônes pour les réduire ou les supprimer.
Hors ligne
Bizarre bizarre...
J'ai testé avec une autre carte son et le problème est le même.
1. Test 2 h (119:53)
2. Test 1h (59:57)
3. Test 1h (59:46)
4. Test 1h (59:41)
5. Test 1h (59:30)
Toutefois ça a l'air de décrocher et de raccrocher à l'heure (à 1 ou 2 secondes près) (à confirmer avec des tops horaires que je programmerai à H+00,00 tout pile).
Hors ligne
Merci.
Le problème est le suivant :
Les émissions s'enregistrent convenablement, pour ça pas de problème.
Cependant, la cadence temporelle de l'enregistrement n'est pas 100% égale à celle du temps qui passe : la durée de l'émission est donc étirée/compactée selon que le coefficient est de 100,1% ou 99,9% (par exemple).
Je suis en train d'étudier des options de l'encodeur MP3 afin de remédier à ce détail.
Hors ligne
Malheureusement c'est pareil : 59mn51sec.
Hors ligne
Renseignements pris, cet effet provient de l'encodeur MP3 (lame.exe) et semble être inhérent aux contraintes de génération des fichiers MP3 (bitrate & fréquence). (voir aussi handle_url_tag($matches[1]), handle_url_tag($matches[1]), handle_url_tag($matches[1]).
Comme ceci ne provient pas de Webradiotools, je ne peux pas apparemment pas apporter de solution simple à ce phénomène.
Ceci dit, la mise à jour handle_url_tag($matches[1]) offre la possibilité :
- d'archiver des logs de diffusion (Diffusion > Historique > Archivage)
- de créer des rapports généraux personnalisés (Diffusion > Rapports > Rapports généraux) au format CSV. Ces rapports peuvent être chronologiques ou regroupés par titre ou artiste (avec tri selon audience, durée, nombre de diffusion ou alphébétique).
Hors ligne
Désolé de ma réponse tardive.
Merci pour les nouvelles fonctionnalités. Je vais les tester.
Un autre souhait : il n'est pas possible qu'une émission chevauche 2 jours (exemple : qu'elle commence à 23h00 et se termine à 00h30). Il est bien possible de la programmer de 23h à 23h59 puis de 00h à 00h29, mais cela donne alors deux enregistrements différents. Est-il possible de remédier à ce problème ?
Merci d'avance.
Hors ligne
Bonjour,
Si une même émission a lieu sur deux jours consécutifs sans interruption à minuit, il n'y a aucune coupure et donc un seul fichier est créé.
Hors ligne
Propulsé par FluxBB