ich möchte eine kleine Verbesserung für zukünftige Versionen vorschlagen. Folgende Situation:
Die Show steht in einer Wartemarke. Unmittelbar mit dem Weiterschalten soll ein asynchrones Tonsample gestartet werden. Schiebt man das Sample genau auf die Wartemarke, startet es bei Erreichen der Wartemarke. Um zu erreichen, dass das Sample erst nach dem Weiterschalten zu starten, muss man es 0.2 ... 0.3 sec hinter die Wartemarke schieben. Vielleicht lässt sich diese Zeit verkürzen, z.B. auf 0.1 sec. Denkbar wäre auch, wenn man in den Sample-Eigenschaften angeben kann, ob selbiges mit Erreichen der Wartemarke oder erst beim Weiterschalten gestartet werden soll.
@Quivertree: Nur ein kleiner Hinweis: Für Wünsche und Anregungen gibts im Forum ein eigenes Kapitel.
So, aber jetzt zurück zum Thema. Die unpräzise Tonwiedergabe von m.objects ist mir schon seit langem ein Dorn im Auge - das ist einem so guten Programm wie m.objects eigentlich nicht würdig.
Dein Beispiel mit dem asynchronen Tonsample nach einer Wartemarke zeigt sehr gut das verheerende Ausmaß dieser Problematik: 0,2 - 0,3 sec. Toleranz ist schon ziemlich heftig.
Ich würde mir folgende Lösung wünschen: Da die kürzeste Zeiteinheit in m.objects die 1/100 sec. ist, sollte ein Tonsample, das genau auf der Wartemarke liegt noch angespielt werden, wenn diese erreicht wird. Liegt das Tonsample dahinter - und sei es nur 0,01 sec. - sollte es bei erreichen der Wartemarke unter keinen Umständen mehr angespielt werden. Und das ganze unabhängig davon, ob es sich um synchronen/asynchronen Ton oder um mp3/wav usw. handelt.
Das gleiche gilt für den Schnitt von Tonsamples. Wenn ich ein Tonsample teile und danach nicht auseinander ziehe, sollte der Ton so abgespielt werden, als wenn er nicht geteilt worden wäre.
Das wäre die Präzision die ich mir wünschen würde.
Dein Hinweis ist berechtigt, mein Beitrag wäre eigentlich unter "Anregungen" besser aufgehoben gewesen. Ursprünglich wollte ich es als "Bug" deklarieren, aber das ging mir dann doch zu weit.
Zurück zur Sache: ich pflichte Dir vollkommen bei. Ich habe vor einiger Zeit schon ein paar Beiträge zum asynchronen Ton geliefert, in denen es um ähnliche Probleme ging. Es müsste doch zu machen sein, Audio-Samples punktgenau (vielleicht nicht unbedingt auf 1/100 sec genau) zu starten. Für Live-Vorträge ist so etwas wesentlich. Vielleicht nimmt Herr Richter sich des Problems noch einmal an.
Um Missverständnissen vorzubeugen:
m.objects arbeitet im normalen Fall mit synchronen Samples und vollkommen exakt. Da gibt es solche Latenzen oder Ungenauigkeiten nicht. Das ist in vielen Fällen ja auch einer der Gründe für den Einsatz dieser Software.
Auch ist ein Schnitt synchroner Samples, an dem das Sample nicht auseinandergezogen wurde, in der Regel nicht hörbar (auch wenn ein solcher Schnitt sicher nicht sinnvoll ist). Lediglich WMA- und nicht zum Standard konforme MP3-Dateien aus externen Systemen können hier kritisch sein, sie lassen sich aber mit m.objects Bordmitteln in ein geeignetes Format wandeln.
Die Einführung asynchroner Tonobjekte hatte zum Ziel, im Bereich von Wartemarken ein Weiterlaufen des Tons trotz angehaltener Präsentation zu ermöglichen. Da hier eben keine synchrone Wiedergabe nötig ist (spätestens ab der ersten Wartemarke auch gar nicht mehr möglich), ist die technisch bedingte Latenz in solchen Anwendungen völlig unerheblich.
Nun entnehme ich Ihren Ausführungen, dass Sie den asynchronen Ton inzwischen völlig anders einsetzen, als wir das vorhergesehen und umgesetzt haben. Vielleicht kann ich Ihnen eine gestalterisch gute und technisch sinnvolle Alternative für die Umsetzung aufzeigen. Dafür müsste ich allerdings ein solches Projekt einmal sehen, um die Intention zu erkennen. Können Sie mir so etwas einmal zukommen lassen?
ich kann Ihnen ein einfaches Beispiel geben: so wie in meinem Eingangsbeitrag beschrieben, steht das Bild, zu dem etwas erläutert werden soll, in einer Wartemarke. Wenn auf das nächste Bild weitergeschaltet wird, soll der Audio-Track gestartet werden. Da dann eine längere Bilderstrecke mit gelegentlichen Wartemarken (oder auch ohne Wartemarken, aber mit der Option auf manuelle Pausen) folgt, habe ich das Sample als asynchron markiert. Also eine durchaus praxisnahe Situation.
Wie bereits erwähnt, ist das Problem nicht so gravierend, dass man damit nicht leben könnte. Aber wenn es eine Lösung gäbe, wäre es trotzdem schön.
Das Beispiel mit dem geschnittenen und nicht auseinandergezogenem Tonsample (was in der Tat nicht sinnvoll ist) habe ich deshalb angeführt, weil ich dachte, daß es dieselbe Ursache hat wie das Problem mit der asynchronen Musik nach einer Wartemarke. Das ist aber offensichtlich nicht so. Ich habe die betroffene MP3-Datei (vermutlich mit WindowsMediaPlayer erzeugt) mit m.objects-Boardmitteln in eine .wav-Datei umgewandelt und diese eingesetzt. Und siehe da - der Schnitt ist nicht mehr hörbar. Vielen Dank für diesen Hinweis.
Allerdings besteht das Problem mit asynchroner Musik nach einer Wartemarke auch mit der .wav-Datei weiterhin. Ich muss das Tonsample ca. 0,2sec nach der Wartemarke platzieren, damit es sicher nicht angespielt wird, wenn der Locater die Wartemarke erreicht. Der Mindestabstand, der benötigt wird, damit das Tonsample nicht angespielt wird variert ein wenig - bei 0,1sec. kommt es noch häufig vor, bei 0,15sec. nur noch selten.
Noch ein Wort zum Praxisbezug dieser Problematik: Die Abspielungenauigkeit nach einer Wartemarke betrifft nicht nur asynchrone Musik. Auch synchrone Musik wird nicht exakt verarbeitet. Bei der synchronen Musik fällt es halt kaum auf, wenn bei der Wartemarke die ersten 0,1sec. angespielt werden (falls man überhaupt irgendetwas bemerkt - wegen Vorlauf, etc.). Bei asynchroner Musik ist das Problem wesentlich heikler, weil die Musik an der Wartemarke dann ja weiterspielt. Wenn man an dieser Stelle Kommentar vorgesehen hat, wirft das die Show durchaus ein wenig durcheinander.
Falls man dieses Problem hat und davon weiß, kann man es in der Regel irgendwie umgehen. Ungut ist nur, wenn man in einer Präsentation von dieser Problematik überrascht wird. Deshalb wäre eine Lösung wünschenswert, wenngleich die Priorität nicht allzu hoch ist.
Kann es sein, dass Hardware/Treiber für dieses Problem verantwortlich sind? Würde es etwas bringen, wenn man einen hochwertigen Audioadapter mit optimiertem ASIO-Treiber verwendet (ich arbeite momentan noch mit Onboard-Sound)?
Danke für Ihre Erläuterungen.
Grundsätzlich dürfte dieses Verhalten abzustellen sein. Ich hatte es mangels Anwendungen dieser Art nur bislang nicht als Problem eingestuft.
Ich kann nicht sicher sagen, ab welcher Version es da Abhilfe geben wird, es steht jetzt aber auf der ToDo Liste.
