Alternative zu iMovie für Capturing?

[cantsin]

Ein Dateiformat verlangt eine Datei. Auf dem Band werden keine Dateien gespeichert.

Hatte ich auch nicht geschrieben, lies noch mal richtig.

[R S K]

Auf dem Band werden keine Dateien gespeichert.

Im Gegensatz wozu? Die sonstigen Bendformate der Zeit? Also waren auf einer Beta SP keine MOV Dateien??! 😳

Wortklauberei. Ich denke so weit kann hier schon noch jeder denken.

[dienstag_01]

Ein Dateiformat verlangt eine Datei. Auf dem Band werden keine Dateien gespeichert.

Hatte ich auch nicht geschrieben, lies noch mal richtig.

Alles gut, dann hatte ich dich falsch verstanden.
Ich wollte nur nochmal darauf hinweisen, dass es kein natives Dateiformat sondern nur Daten gibt, die beim Capturen in eine Datei geschrieben werden.
Da man in einigen NLEs beim Capturen den Codec frei wählen kann, liegt dort eine Fehlerquelle. Nativ ist da nichts. Im Gegensatz zu z.B. HDVsplit, dass kann wirklich nur den Datenstrom in einen MPEG2-Transportstream schreiben.

[Asjaman]

Asjaman:

„ Wenn ich zB ein Video mit Stereo-Audio (als 2 embedded Audio Channels in einer Stereo-Spur) mit zwei Interview-Stimmen hart links und hart rechts habe“

Das ist kein Stereo. und auch keine Stereospur. Ich geb‘s auf, das ist wie gegen eine Wand reden! :-)

Himmel, ist es jetzt mal genug? Das war doch längst klargestellt.

Dass eine Audioaufnahme mit zwei simultan aufzeichnenden Kanälen noch keine Stereo-Aufnahme bedeutet, die einen räumlichen Höreindruck erzeugt - darüber müssen wir nicht diskutieren.

Dennoch schimpft sich eine zweikanalige Audiospur im Schnittprogramm "stereo" / 2.0 - einfach als synonym für zweikanalig, naturgemäß ohne Unterscheidung, ob bei der Aufnahme die beiden Mikros sorgsam nebeneinander auf einer Stereoschiene oder das eine im Wohnzimmer und das andere in der Besenkammer positioniert sind.

sample1.jpg

Um mal den Bogen zurück zum Topic zu schlagen: Es ging hier seit diesen Beispieltexten aus MediaInfo um die Frage, wie das Channel Layout vom Audio in Capture-Dateien angelegt wird.

[Skeptiker]

Zum gestrigen Video-Test mit einem alten MiniDV-Band (siehe Seite vorher):
viewtopic.php?f=29&t=157981&start=35#p1173336

Da wollte ich einfach wissen, wie das Capturing nur mit Mac-Bordmitteln funktioniert (in diesem Fall offenbar ein altes MacBook 2011 mit Mac OS 10.8.5, gedacht vor allem fürs DV- und HDV-Capturing).
iMovie war vom Fragesteller ja ausgeschieden worden, Final Cut hat nicht jeder installiert (ja, ich weiss, es gibt von FCP X Demo-Versionen), also blieb noch QuickTime (7 oder 10).

Das Capturing mit QuickTime 10.5 unter macOS 10.14.6 ergab dann in maximaler Qualitätsstufe ProRes statt natives DV, und zwar progressive 25p statt interlaced 50i. Das war von mir weder so eingestellt noch gewollt, sondern schlicht das Capture-Ergebnis.

RSK hat darauf hingewiesen, dass das ProRes-File mit 40.3 Mbit/s (MediaInfo) aufgebläht sei, ohne einen Informationsgewinn und dass das ProRes-Encoding hier im Prinzip keinen Sinn ergibt.
cantsin weist wiederholt darauf hin, dass man mit Vorteil im nativen DV-Format capturen sollte.

Der Einwand mit der zusätzlichen, überflüssigen Leer-Information ist sicher richtig, man kann sich höchstens fragen, ob das Endergebnis in ProRes durch den professionellen Codec besser aussieht als in DV (wenn beide zum fairen Vergleich interlaced wären - mit FCP 7/10 ginge das Interlaced-Capturen von DV-Quelle nach ProRes wohl, habe es aber nicht ausprobiert und weiss es deshalb nicht).

Vergleich der beiden Formate
DV PAL (Quellformat):
Chroma (und Luma) Sampling: 4:2:0 -> 6 (4+2+0)
Bit-Tiefe: 8 bit

ProRes (Zielformat):
Chroma Sampling: 4:2:2 -> 8 (4+2+2)
Bit-Tiefe: 10 bit

Zurückrechnen der Datenrate von ProRes 40.3 Mbit/s auf DV PAL 25 mit 24.4 Mbit/s (MediaInfo):

40.3 Mbit/s * (6/8) * (8/10) = 24.18 Mbit/s (also etwa 24.4 wie das Original-DV), d.h. die ProRes-Datei ist tatsächlich aufgeblasen mit Leerinformation!

Ich hab's ja schon ein paarmal geschrieben: Der QuickTime Capture-Test mit einem HDV-Band (bzw. DV-Band mit HDV-Aufnahme) wäre ebenfalls interessant, aber ich habe leider keine solche Vorlage und Asjaman hat vielleicht keine Zeit und - nach der Audio-Diskussion mit gegenseitigen Wortverdrehungen und "Ich bin schlau und Ihr seid doof"-Gehabe - vielleicht auch keine Lust.

Okay, das war's für den Moment - ich komme später vielleicht noch aufs Audio und "Viel Lärm um nichts" zurück!
Möchte die gestern abgeholte, neue Fuji X-H2S noch etwas testen! ;-)

[cantsin]

Der Einwand mit der zusätzlichen, überflüssigen Leer-Information ist sicher richtig, man kann sich höchstens fragen, ob das Endergebnis in ProRes durch den professionellen Codec besser aussieht als in DV (wenn beide zum fairen Vergleich interlaced wären - mit FCP 7/10 ginge das Interlaced-Capturen von DV-Quelle nach ProRes wohl, habe es aber nicht ausprobiert und weiss es deshalb nicht).

Da liegt eben der Denkfehler.

Das Video liegt auf dem Band bereits im DV-Codec vor.

Bei Deiner Capture-Lösung wird es von DV nach ProRes umcodiert. D.h. Du verlierst sogar Bildqualität (weil jede verlustbehaftete Kompression definitionsbedingt qualitätsverlustbehaftet ist, selbst wenn in diesem Fall nur in geringem Maße).

Es ist nicht so, dass da ein rohes Videosignal vom Band gecaptured und anschließend entweder im DV- oder ProRes-Codec encodiert oder gespeichert wird. Das ist immer noch Denkfehler, der bei vielen Leuten (verständlicherweise) im Kopf sitzt, die mal mit analogen Videokassettenformaten und derem Capturing angefangen haben.

Vergleich der beiden Formate
DV PAL (Quellformat):
Chroma (und Luma) Sampling: 4:2:0 -> 6 (4+2+0)
Bit-Tiefe: 8 bit

ProRes (Zielformat):
Chroma Sampling: 4:2:2 -> 8 (4+2+2)
Bit-Tiefe: 10 bit

Die 10bit sind zwei Nullen Luft, weil DV-Video codec-/aufzeichnungstechnisch-bedingt nur 8bittig ist. Ebenso gibt es auch nur 4:2:0-Chromasampling im aufgezeichneten Material und erzielst Du daher auch mit ProRes keine 4:2:2.

Wie gesagt, es ist genau das gleiche, als wenn Du ein mit einer Fotokamera aufgenommenes 8bit-JPEG als 16bit-TIFF speicherst... [Sogar sehr gut vergleichbar, weil der DV-Codec mit JPEG technisch eng verwandt ist.]

[Skeptiker]

Der Einwand mit der zusätzlichen, überflüssigen Leer-Information ist sicher richtig, man kann sich höchstens fragen, ob das Endergebnis in ProRes durch den professionellen Codec besser aussieht als in DV (wenn beide zum fairen Vergleich interlaced wären - mit FCP 7/10 ginge das Interlaced-Capturen von DV-Quelle nach ProRes wohl, habe es aber nicht ausprobiert und weiss es deshalb nicht).

Da liegt eben der Denkfehler.

Das Video liegt auf dem Band bereits im DV-Codec vor.

Hallo cantsin,

Ich war schon halb im Aufbruch, da fiel mir ein, dass genau dieser Teil missverständlich bzw. falsch ist. Wollte es gerade noch korrigieren, aber war mir sicher, dass darauf schnell die Erwiderung kommen würde, die nun von Dir kommt. Gut aufgepasst!

Ja stimmt - das Video ist bereits in den "DV-Brunnen" gefallen - es ist bereits mit einem nach heutigen Ansprüchen eher mittelmässigen Codec kodiert!

Es würde auch keinen Unterschied machen, zunächst in DV zu capturen und anschliessend nach ProRes umzurechnen.
Das Einzige, was ich mir von einem ProRes-Kodieren erhoffen würde, ist eine nachträgliche Korrektur der starken Aliasing-Effekte von DV-Material (es gibt bei geometrischen Objekten mit im Bild bewegten Kanten aller Art ein Konturenflimmern, das mir gesten am Monitor wieder deutlich auffiel).
Und zweitens zusätzlich mehr Bildqualität, falls ich über mehrere Durchgänge in unterschiedlichen Programmen gehen müsste und dabei immer wieder Zwischenspeichern würde (dann eben in ProRes/ ProRes HQ).

Die Lösung könnte sein, analog aus dem Camcorder zu gehen und so den DV Codec zu umgehen. Aber das ginge auch nur sinnvoll live mit einem externen Aufnahmegerät, ansonsten müsste die Aufnahme ja zunächst im der Kamera gespeichert werden und ist dann eben schon DV-kodiert.
Mein Panasonic DV-Camcorder AG-DVC30 zeigt live im Record-Modus per S-Video direkt am TV (quasi als Vorschaumonitor) ein klar besseres Bild, als wenn das gleiche Bild zunächst auf DV-Band gespeichert und anschliessend ebenfalls per S-Video am TV betrachtet wird.
Ich habe mir damals bereits nach dem kurz Kauf den Kopf zerbrochen, ob ich das DV-Tape irgendwie extern umgehen könnten aber keine Lösung gefunden (externes MPEG-2 ging nur für HDV).

So - jetzt aber schnell auf und davon .. .. ;-)

[dienstag_01]

Da liegt eben der Denkfehler.

Das Video liegt auf dem Band bereits im DV-Codec vor.

Hallo cantsin,

Ich war schon halb im Aufbruch, da fiel mir ein, dass genau dieser Teil missverständlich bzw. falsch ist. Wollte es gerade noch korrigieren, aber war mir sicher, dass darauf schnell die Erwiderung kommen würde, die nun von Dir kommt. Gut aufgepasst!

Ja stimmt - das Video ist bereits in den "DV-Brunnen" gefallen - es ist bereits mit einem nach heutigen Ansprüchen eher mittelmässigen Codec kodiert!

Es würde auch keinen Unterschied machen, zunächst in DV zu capturen und anschliessend nach ProRes umzurechnen.
Das Einzige, was ich mir von einem ProRes-Kodieren erhoffen würde, ist eine nachträgliche Korrektur der starken Aliasing-Effekte von DV-Material (es gibt bei geometrischen Objekten mit im Bild bewegten Kanten aller Art ein Konturenflimmern, das mir gesten am Monitor wieder deutlich auffiel).
Und zweitens zusätzlich mehr Bildqualität, falls ich über mehrere Durchgänge in unterschiedlichen Programmen gehen müsste und dabei immer wieder Zwischenspeichern würde (dann eben in ProRes/ ProRes HQ).

Die Lösung könnte sein, analog aus dem Camcorder zu gehen und so den DV Codec zu umgehen. Aber das ginge auch nur sinnvoll live mit einem externen Aufnahmegerät, ansonsten müsste die Aufnahme ja zunächst im der Kamera gespeichert werden und ist dann eben schon DV-kodiert.
Mein Panasonic DV-Camcorder AG-DVC30 zeigt live im Record-Modus per S-Video direkt am TV (quasi als Vorschaumonitor) ein klar besseres Bild, als wenn das gleiche Bild zunächst auf DV-Band gespeichert und anschliessend ebenfalls per S-Video am TV betrachtet wird.
Ich habe mir damals bereits nach dem kurz Kauf den Kopf zerbrochen, ob ich das DV-Tape irgendwie extern umgehen könnten aber keine Lösung gefunden (externes MPEG-2 ging nur für HDV).

So - jetzt aber schnell auf und davon .. .. ;-)

Für diese Artefakte gibt es Effekte, ich kenne DV Fixer von Boris FX.

[cantsin]

Für diese Artefakte gibt es Effekte, ich kenne DV Fixer von Boris FX.

Die KI-Videoverbesserungs-Tools von Topaz bügeln solche Artefakte auch aus.

Es handelt sich um ganz simple Block-Artefakte, wie man sie auch bei niedriger JPEG-Qualität bekommt. Mehr zu dem Thema hier:

https://en.wikipedia.org/wiki/Compressi ... act#Images

[MK]

Die KI-Videoverbesserungs-Tools von Topaz bügeln solche Artefakte auch aus.

Es handelt sich um ganz simple Block-Artefakte, wie man sie auch bei niedriger JPEG-Qualität bekommt. Mehr zu dem Thema hier:

https://en.wikipedia.org/wiki/Compressi ... act#Images

Die typischen DV-Artefakte sind vor allem bei PAL DV Treppenstufen an harten Farbübergängen durch die 4:2:0 Farbunterabtastung und dem gegenüber MPEG-2 mit ebenfalls 4:2:0 Farbunterabtastung ungünstiger gelegenen Samplepunkt für die Chrominanz... kriegt man mit VirtalDub oder Avisynth programmintern weg, oder mit Drittherstellerdecodern (von Mainconcept gab es mal einen) welche die Farbinformationen ebenfalls hochinterpolieren konnten.

[Jott]

Ich wollte nur nochmal darauf hinweisen, dass es kein natives Dateiformat sondern nur Daten gibt, die beim Capturen in eine Datei geschrieben werden.
Da man in einigen NLEs beim Capturen den Codec frei wählen kann, liegt dort eine Fehlerquelle. Nativ ist da nichts. Im Gegensatz zu z.B. HDVsplit, dass kann wirklich nur den Datenstrom in einen MPEG2-Transportstream schreiben.

Noch einer …

Jedes Schnittprogramm nimmt den MPEG 2-Transport-Stream, legt lediglich einen ihm genehmen Wrapper drumrum und popelt die beiden Audiospuren aus dem Stream. Das war‘s. Nennt man schon immer nativ. Bit für Bit. Und so wird dann auch geschnitten.

Codec frei wählen? Wenn man von hinten durch die Brust über analoge Wege einspielt, dann ja. Aber ich dachte, wir sind bei FireWire?

[dienstag_01]

Ich wollte nur nochmal darauf hinweisen, dass es kein natives Dateiformat sondern nur Daten gibt, die beim Capturen in eine Datei geschrieben werden.
Da man in einigen NLEs beim Capturen den Codec frei wählen kann, liegt dort eine Fehlerquelle. Nativ ist da nichts. Im Gegensatz zu z.B. HDVsplit, dass kann wirklich nur den Datenstrom in einen MPEG2-Transportstream schreiben.

Noch einer …

Jedes Schnittprogramm nimmt den MPEG 2-Transport-Stream, legt lediglich einen ihm genehmen Wrapper drumrum und popelt die beiden Audiospuren aus dem Stream. Das war‘s. Nennt man schon immer nativ. Bit für Bit. Und so wird dann auch geschnitten.

Codec frei wählen? Wenn man von hinten durch die Brust über analoge Wege einspielt, dann ja. Aber ich dachte, wir sind bei FireWire?

Geht auch über Firewire.
Reg dich wieder ab.
Man muss sich doch nun nicht gegen jede Erkenntnis wehren.
Ausserdem ist es lange her, dass das mal wirklich relevant war.

[Jott]

Zum Hintergrund des „Aufregens“:

Wir hatten in den Jahren 2005 bis 2008 sehr sehr viel mit HDV-Kameras von Sony produziert. Teures Auftragszeug für die Industrie. HD-Aufnahmen waren bis darin ein sechsstelliger Spaß, plötzlich kamen diese Camcorder für 5.000 Euro. Die Klassiker: Z1, dann Z7.

Technisch war das so einfach wie alles andere, nein, sogar viel einfacher: Aufnehmen, Einspielen via FireWire (Mac), Schneiden. War ja auch nichts exotisches, der Codec ist heute noch Weltstand im Broadcast-Bereich. In allen Kameras, die XDCAM nutzen, findet sich auch heute noch „HDV“ (MPEG 2 mit 25 Mbit). Wegen eines gut gefüllten Archivs tuckert auch heute noch bei uns eine HDV-MAZ (unzerstörbar wie alle früheren Sony-MAZen), um an alte Sachen ran zu kommen.

Also: wieso dieses zum Teil unglaubliche Geschwurbel in diesem Thread zu einem stinknormalen Videoformat? Oder auch zu DV?Das lässt einen einfach ratlos zurück.

Die Tonverwirrungen sind einfach solche per se, hat nichts mit DV oder HDV oder sonstigen Formaten zu tun. Mindestens zwei getrennte Tonspuren haben alle, damals wie heute.

[dienstag_01]

Zum Hintergrund des „Aufregens“:

Wir hatten in den Jahren 2005 bis 2008 sehr sehr viel mit HDV-Kameras von Sony produziert. Teures Auftragszeug für die Industrie. HD-Aufnahmen waren bis darin ein sechsstelliger Spaß, plötzlich kamen diese Camcorder für 5.000 Euro. Die Klassiker: Z1, dann Z7.

Technisch war das so einfach wie alles andere, nein, sogar viel einfacher: Aufnehmen, Einspielen via FireWire (Mac), Schneiden. War ja auch nichts exotisches, der Codec ist heute noch Weltstand im Broadcast-Bereich. In allen Kameras, die XDCAM nutzen, findet sich auch heute noch „HDV“ (MPEG 2 mit 25 Mbit). Wegen eines gut gefüllten Archivs tuckert auch heute noch bei uns eine HDV-MAZ (unzerstörbar wie alle früheren Sony-MAZen), um an alte Sachen ran zu kommen.

Also: wieso dieses zum Teil unglaubliche Geschwurbel in diesem Thread zu einem stinknormalen Videoformat? Oder auch zu DV?Das lässt einen einfach ratlos zurück.

Die Tonverwirrungen sind einfach solche per se, hat nichts mit DV oder HDV oder sonstigen Formaten zu tun. Mindestens zwei getrennte Tonspuren haben alle, damals wie heute.

Fein, Jott, und jetzt schaust du mal, ob dein NLE dich "zwingt", in HDV zu capturen? Je länger ich darüber nachdenke, um so weniger wahrscheinlich halte ich das. Gerade für HDV bietet sich doch ein Standardformat mit 1920 Pixeln in der Breite an.

[Jott]

Es gibt über FireWire keine „Auswahl“ zum Capturen. Ist immer HDV, je nachdem. Nativ halt.

Ich kann mir nicht vorstellen, dass du das nicht weißt. Du tust nur so. Warum?

Irgendeine Umwandlung wäre obendrein sinnlos, gerade weil alle NLEs seit spätestens 15 Jahren perfekt mit MPEG 2 Long GoP umgehen können. Nein, müssen, wegen diesem heißgeliebten Broadcast-Format, das nie ausstirbt. Nur Consumer-Software, die nichts mit Broadcastformaten zu tun haben will, wandelt zuweilen zu irgendwas um. Das ist dann aber dem eigentlichen Einspiel-Vorgang nachgelagert, denn über FireWire ... blabla, zum zehnten Mal ...geht's nur nativ.

Dass ein schlauer NLE erkennt, wenn anamorphes Material in die Timeline purzelt und automatisch zur korrekten Wiedergabe entsprechend die Darstellung stretcht, sollte auch nichts Neues sein.

[dienstag_01]

Es gibt über FireWire keine „Auswahl“ zum Capturen. Ist immer HDV, je nachdem. Nativ halt.

Ich kann mir nicht vorstellen, dass du das nicht weißt. Du tust nur so. Warum?

Irgendeine Umwandlung wäre obendrein sinnlos, gerade weil alle NLEs seit spätestens 15 Jahren perfekt mit MPEG 2 Long GoP umgehen können. Nein, müssen, wegen diesem heißgeliebten Broadcast-Format, das nie ausstirbt. Nur Consumer-Software, die nichts mit Broadcastformaten zu tun haben will, wandelt zuweilen zu irgendwas um. Das ist dann aber dem eigentlichen Einspiel-Vorgang nachgelagert, denn über FireWire ... blabla, zum zehnten Mal ...geht's nur nativ.

Dass ein schlauer NLE erkennt, wenn anamorphes Material in die Timeline purzelt und automatisch zur korrekten Wiedergabe entsprechend die Darstellung stretcht, sollte auch nichts Neues sein.

Ich glaube mich zu erinnern, dass ich im Avid den Codec auswählen konnte. Es kann aber sein, dass ich das mit dem Import von Transport-Streams verwechsel. Öfter als über Avid habe ich über externe Tools gecaptured, das lief besser, gerade auf dem Laptop.
Und weil ich oft gemischtes Material in der Timeline hatte, habe ich die HDV Files zu square-Pixel-Material "aufgeblasen", ich wollte alles so gut selber kontrollieren wie es geht. Für die Ausgabe brauchte ich 25p, dazu musste zumindest ein Teil deinterlaced werden, anamorphes Material hat mich da verunsichert. Egal, würde ich vielleicht heute anders machen.
Der Beginn liegt aber auch länger als die von dir genannten 15 Jahre zurück, damals war das alles Neuland und bei LongGOP-Material hab ich nur Bahnhof verstanden ;)

Halten wir mal fest, über Firewire kommt eine 1:1-Kopie in den Rechner, egal in welchem Dateiformat. Mein Fehler.

[Jott]

AVID hatte erst spät ein FireWire-Modul für nativen Import angeboten (für stramme 10.000 DM oder so), das natürlich kaum jemand gekauft hatte, da DV und danach HDV im "Profimarkt" verpönt waren. Währenddessen hatte Apple den explodierenden Markt rund um DV/DVCAM/DVCPro und dann auch HDV und DVCPro HD (alles FireWire!) mit perfekt passender Hard- und Software längst an sich gezogen und damit zum damaligen fcp-Höhenflug angesetzt. Nicht ganz verwunderlich, weil FireWire ja ein Baby von Apple und Sony war. Panasonic war auch schnell aufgesprungen.

Dass du als AVID-Mensch, beheimatet neben einem fönenden klimatisierten Raum voller Betacam- und HDCAM-MAZen in dieser Zeit auf einem anderen Planeten warst, ist klar. Du konntest ja vieles gar nicht wissen oder mitbekommen - es war die Zeit, als man fcp noch gepflegt ausgelacht hatte. Spannende Zeiten waren das, da wurde so einiges auf den Kopf gestellt.

Das war übrigens auch die Zeit, als wir quasi über Nacht mehrere sechsstellige AVIDs plus Beta-MAZen abgestoßen hatten (ja, ich hatte einen der ersten AVIDs in Europa). Was Anfang der 90er visionär war, war um 2000 herum für unsere Zwecke aus der Zeit gefallen. Hatten nur wenige so gesehen, aber damit begann eine sehr, sehr erfolgreiche Zeit.

Ich schweife ab! :-)

Kleine Anmerkung noch: Es gab große Schulterboliden (2/3“) mit DV-Laufwerk von Sony und Ikegami für Anspruchsvolle. Das sah natürlich um Welten besser aus als das Bild der „Kleinen“! Wer wusste, was er will …

[dienstag_01]

Für mich als Windows-Nutzer war die DV-Revolution eher mit Premiere verbunden ;)

[MK]

Es gibt über FireWire keine „Auswahl“ zum Capturen. Ist immer HDV, je nachdem. Nativ halt.

Es gibt und gab einige Programme wo man beim Aufzeichnen den 1:1 Datenstrom direkt transkodieren konnte, was dann wohl so wirkte als ob das eine Art "Formatauswahl" ist. Ähnlich heute wenn man bei Blackmagic, AJA, etc. Uncompressed einspielt und das Captureprogramm das je nach Einstellung direkt in Echzeit in was Verlustbehaftetes umrechnet. "Schau mal die 30 Jahre alte Digibeta konnte schon ProRes und H.264" *lol*

Ich habe schon viel Unsinn gesehen, auch eine Firma die vor 16 Jahren noch DVDs mit Werbe-Showreels kommerziell als Katalog angeboten hat und das Quellmaterial per Composite in Echtzeit von nem DVD-Player eingespielt hat... nachdem ich denen gezeigt habe wie man das easy per Laufwerk rippt steht denen wahrscheinlich heute noch der Mund offen.

[Jott]

Um mal den Bogen zurück zum Topic zu schlagen: Es ging hier seit diesen Beispieltexten aus MediaInfo um die Frage, wie das Channel Layout vom Audio in Capture-Dateien angelegt wird.

Nach dem langen Exkurs in die spannende Geschichte von HDV:
Weißt du jetzt Bescheid, oder bist du immer noch am Grübeln?

[Asjaman]

Um mal den Bogen zurück zum Topic zu schlagen: Es ging hier seit diesen Beispieltexten aus MediaInfo um die Frage, wie das Channel Layout vom Audio in Capture-Dateien angelegt wird.

Nach dem langen Exkurs in die spannende Geschichte von HDV:
Weißt du jetzt Bescheid, oder bist du immer noch am Grübeln?

Hallo Jott,
danke, ich komme klaglos zurecht. :-)
Für mich ist es in erster Linie erfreulich, dass die Sache sowohl bei DV wie bei HDV technisch klappt und die alte MAZ ganz anstandslos nach so langer Zeit des Nichtbenutzens ihren Job macht.

Was das Audio betrifft, so hätte mich nur interessiert, warum bei via Firewire eingelesenen HDV-Cassetten grundsätzlich zwei Audiospuren Mono L und Mono R im Transportstream angelegt werden (MOV Datei), während es in der M2T Datei vom Sony HDV-Recorder (der auf CF aufnimmt) eine Audiospur mit 2 Kanälen ist.
Nicht dass mich das stört, man kann ja alles im NLE handlen und erstmal den jeweiligen Spurtypen zuordnen und bei Bedarf splitten, den Rest machen die Ohren.
Es fiel mir nur auf und ich hatte dafür keine naheliegende Erklärung. Ich hätte zB erwartet, dass HDV Aufnahmen vom Consumer Canon HV20 mit Audio vom integrierten Stereo-Mikro eine 2-kanalige Audiospur LR erzeugen, dem ist aber nicht so, es wird Mono L und Mono R auf je einer Spur.

[Jott]

"während es in der *.m2t Datei vom Sony HDV-Recorder (der auf CF aufnimmt) eine Audiospur mit 2 Kanälen ist."

Okay. Es gibt immer noch keine zweikanaligen Audiospuren! :-)

Du stolperst wahrscheinlich über eine Darstellung in deinem Schnittprogramm (welches eigentlich?) - das dir zwei Spuren als eine Stereospur "verkauft", wozu auch immer. Denn wissen, ob es tatsächlich eine Stereoaufnahme ist, kann es nicht. Aus der Kamera kommt so was jedenfalls nicht, da gibt es nur zwei getrennte Spuren.

Sony: Unterschiede zwischen Transportstream von Band und CF? Hatte ich nie mitbekommen, den Anklickrecorder hatten wir auch. War immer völlig egal, was man einliest. Ergebnis natürlich immer zwei getrennte Spuren.

Canon: bei denen halte ich mich raus. Die Firma - so gut sie heute auch ist - hatte damals in vielen Punkten auf die festgelegte HDV-Norm gesch ..., worunter heute noch viele leiden, die an altes Cassettenmaterial ran wollen. Traurig.


Wie gesagt, ich glaube, es ist dein Schnittprogramm, das dich durch eine komische Darstellung ins Grübeln bringt, sonst nichts.

[MK]

"während es in der *.m2t Datei vom Sony HDV-Recorder (der auf CF aufnimmt) eine Audiospur mit 2 Kanälen ist."

Okay. Es gibt immer noch keine zweikanaligen Audiospuren! :-)

Du stolperst wahrscheinlich über eine Darstellung in deinem Schnittprogramm (welches eigentlich?) - das dir zwei Spuren als eine Stereospur "verkauft", wozu auch immer. Denn wissen, ob es tatsächlich eine Stereoaufnahme ist, kann es nicht. Aus der Kamera kommt so was jedenfalls nicht, da gibt es nur zwei getrennte Spuren.

Sony: Unterschiede zwischen Transportstream von Band und CF? Hatte ich nie mitbekommen, den Anklickrecorder hatten wir auch. War immer völlig egal, was man einliest. Ergebnis natürlich immer zwei getrennte Spuren.

Canon: bei denen halte ich mich raus. Die Firma - so gut sie heute auch ist - hatte damals in vielen Punkten auf die festgelegte HDV-Norm gesch ..., worunter heute noch viele leiden, die an altes Cassettenmaterial ran wollen. Traurig.


Wie gesagt, ich glaube, es ist dein Schnittprogramm, das dich durch eine komische Darstellung ins Grübeln bringt, sonst nichts.

Bei MXF und ProRes kann man allerdings die Kanäle "gruppieren" und auch Angaben hinterlegen ob das Mono, Stereo, oder whatever sein soll... ich musste mal einem Kunden hunderte Masterdateien für ne Austrahlung umstricken weil die Monokanäle 1-2, 3-4 jeweils als Stereopärchen getaggt waren (was sie in dem Falll ja auch tatsächlich waren, einmal deutsch, einmal englisch)... obwohl jede Software das problemlos als Kanal 1 - 4 importiert hat bestanden die darauf das Layout auf 1 - 4 als Monospuren getaggt abzuändern.

[Jott]

Ja, die mxf-Welt beschäftigt sich gern mit solchen Dingen.

Ich persönlich habe eine Broadcaster-Allergie, mit denen kann ich nicht.

[MK]

Ja, die mxf-WElt beschäftigt sich gern mit solchen DIngen.

Für Rätselfreunde gibt's immer noch MAZ-Karten! :-)

Richtig, leider wird man diese Altlasten auch nicht los weil man sich die Investition in einen dateibasierten Transfer spart bis es gar nicht mehr anders geht... wobei bei Ersatzteilen für Digibetas langsam auch die Luft dünn wird und die Leute die sich noch damit auskennen auch immer rarer gesäht sind.

Davon abgesehen werden die Bänder auch nicht besser.

[MK]

Ich persönlich habe eine Broadcaster-Allergie, mit denen kann ich nicht.

Ich brauche das Geld... :-(

[Asjaman]

"während es in der *.m2t Datei vom Sony HDV-Recorder (der auf CF aufnimmt) eine Audiospur mit 2 Kanälen ist."

Okay. Es gibt immer noch keine zweikanaligen Audiospuren! :-)

Du stolperst wahrscheinlich über eine Darstellung in deinem Schnittprogramm (welches eigentlich?) - das dir zwei Spuren als eine Stereospur "verkauft", wozu auch immer. Denn wissen, ob es tatsächlich eine Stereoaufnahme ist, kann es nicht. Aus der Kamera kommt so was jedenfalls nicht, da gibt es nur zwei getrennte Spuren.

Sony: Unterschiede zwischen Transportstream von Band und CF? Hatte ich nie mitbekommen, den Anklickrecorder hatten wir auch. War immer völlig egal, was man einliest. Ergebnis natürlich immer zwei getrennte Spuren.

Canon: bei denen halte ich mich raus. Die Firma - so gut sie heute auch ist - hatte damals in vielen Punkten auf die festgelegte HDV-Norm gesch ..., worunter heute noch viele leiden, die an altes Cassettenmaterial ran wollen. Traurig.


Wie gesagt, ich glaube, es ist dein Schnittprogramm, das dich durch eine komische Darstellung ins Grübeln bringt, sonst nichts.

danke dir.

Worauf ich mich hier beziehe, das sind die Dateiattribute von jeweils MOV und M2T hinsichtlich Audio, nachzulesen im Analyse-Programm MediaInfo oder auch VideoSpec
Und wenn ich die erwähnten Dateien M2T und MOV in Davinci Resolve importiere und Clip Attributes aufrufe, so zeigt
sich für M2T:

m2t.jpg

Völlig klar: weder Kamera noch NLE wissen, ob es sich bei zwei Spuren um echtes stereo handelt oder nicht, es wird einfach nur erkannt, dass man es hier mit zwei "zusammengefassten" Kanälen für eine Spur mit dem Track Type 2.0 zu tun hat.

Die MOV Datei zeigt:

mov.jpg

und Resolve freut sich auf zwei getrennt dargestellte 1.0 Audiospuren in der Timeline.

Jott:
eine Darstellung in deinem Schnittprogramm, das dir zwei Spuren als eine Stereospur "verkauft", wozu auch immer
ganz genau, und so war es seit eh und je, bei Premiere, Avid, Resolve. Und da dies am Quellmaterial liegt, hat mich die dortige Ursache interessiert.

Aber wie schon gesagt: ich komme zurecht, alles halb so schlimm ;-) Es lässt sich ja auch alles umdefinieren im Fenster für die Attributes, siehe Grafiken.

Ich persönlich habe eine Broadcaster-Allergie, mit denen kann ich nicht.
sympathisch

[Jott]

MOV-Datei aus einer HDV-Kamera? Unfug. Das ist ein Schluckauf bei denen, digitale Verpeilung.

Oder sieht das jemand ernsthaft anders?

[Asjaman]

MOV-Datei aus einer HDV-Kamera? Unfug. Das ist ein Schluckauf bei denen, digitale Verpeilung.

Oder sieht das jemand ernsthaft anders?

Naja, das ist eben der Container, den FCP7 beim Abspeichern der Firewire-Signale nutzt.

[Jott]

fcp 7-Feinheiten (letzte Version 2009 oder noch älter?) weiß ich nicht mehr. Aber ich meine mich zu erinnern, man konnte bei Kanalinterpretationen was einstellen. Egal.

Aber jetzt sind wir einen Schritt weiter: du redest die ganze Zeit gar nicht vom Capturen, sondern von der Übergabe bereits eingespielten Materials von einem NLE zum anderen?

Ist immerhin ein netter Thread draus geworden.

[Asjaman]

du redest die ganze Zeit gar nicht vom Capturen, sondern von der Übergabe bereits eingespielten Materials von einem NLE zum anderen?

Ich rede von den Eigenschaften der resultierenden Dateien, da ist das Capturing doch längst passé. Zuletzt kamen noch Files aus dem HDV Recorder hinzu (von CF Karte, *.m2t)

iMovie (DV) und dann FCP7 (für HDV) sind nur die Werkzeuge, alle Capture-Dateien kopiere ich unverändert aus den Dokumentordnern vom iMac zum PC. *.dv muss rewrapped werden zu *.mov, da sonst von Resolve nicht lesbar. Siehe Posting #1 und weitere.
*.mov mit HDV Codec wird direkt von Resolve akzeptiert.

Noch irgendwas unklar? ;-)

[Jott]

Ja, dein weiteres Schicksal! :-)

[Asjaman]

Ja, dein weiteres Schicksal! :-)

Ein schönes Schlusswort.