Infoseite // Alternative zu iMovie für Capturing?

Frage von Asjaman:


Hallo zusammen!

Kennt jemand eine günstige Alternative zu iMovie, um HDV Material über Firewire in einen iMac zu capturen?
Einschränkung: der Computer ist von 2011 und darauf läuft nichts Neueres als OS X 10.8.5

iMovie konnte ich wunderbar nutzen, um DV Cassetten mit SD Auflösung via Firewire zu capturen, die resultierenden *.dv Clips rewrappe ich zu *.mov und kann sie dann unter Windows in Resolve bearbeiten.
Bei HDV jedoch erzeugt iMovie zwingend AIC mov-Dateien (also Apple Intermediate Codec) , mit denen ich so nichts anfangen kann. Sie müssen erst transkodiert werden.

Gibt es eine Software, die auf dem alten OS läuft und das HDV nativ abspeichert, also so etwas wie *.m2t oder dergleichen?
FCP7 habe ich auch auf dem Mac, jedoch gibt es da einen Bug beim Capturing bez. Framerate (erzeugt krumme Werte knapp neben 25 fps, zB 24.94 fps)

Vielen Dank und Grüße!



Antwort von Skeptiker:

Asjaman hat geschrieben:
Hallo zusammen!

Kennt jemand eine günstige Alternative zu iMovie, um HDV Material über Firewire in einen iMac zu Capturen?
Einschränkung: der Computer ist von 2011 und darauf läuft nichts Neueres als OS X 10.8.5

iMovie konnte ich wunderbar nutzen, um DV Cassetten mit SD Auflösung via Firewire zu capturen, die resultierenden *.dv Clips rewrappe ich zu *.mov und kann sie dann unter Windows in Resolve bearbeiten.
Bei HDV jedoch erzeugt iMovie zwingend AIC mov-Dateien (also Apple Intermediate Codec) , mit denen ich so nichts anfangen kann. Sie müssen erst transkodiert werden.

Gibt es eine Software, die auf dem alten OS läuft und das HDV nativ abspeichert, also so etwas wie *.m2t oder dergleichen?
FCP7 habe ich auch auf dem Mac, jedoch gibt es da einen Bug beim Capturing bez. Framerate (erzeugt krumme Werte knapp neben 25 fps, zB 24.94 fps)

Vielen Dank und Grüße! QuickTime 7 oder X müsste auch gehen (allerdings setzen iMovie und FCP 7 darauf auf) - 'native' in DV sicher mit QT7, aber nativ mit HDV ?? Sonst wäre wohl die beste (verlustloseste, aber speicherfressende) Alternative, mit ProRes zu capturen.
Was den angeblichen Bug beim Capturen mit FCP 7 betrifft (Du schreibst nicht, in welches Format/Codec): Ein mts/mp4 (lässt sich ineinander um'wrappen' mit remux 1.4) könntest Du z. B. mit HandBrake in eine konstante, gerade Bildrate umrechnen (constant frame rate - CFR).

Ich habe mich noch etwas umgesehen:

Im Wikipedia-Kapitel zu HDV werden die beiden Formate HDV 1 und HDV 2 detailliert beschrieben.
HDV 1 ist 720p, also 720x1280 progressive
HDV 2 ist 1080i, in diesem Fall 1440x1080 interlaced, wobei 1440 horizontal dann zur Anzeige auf 1920 gestreckt wird.
Beide Formate mit MPEG-2 GOP (Group Of Pictures) Codec. Damit wärst Du bereits in der Nähe von Apples AIC Codec, der ebenfalls MPEG-2 ist, aber nicht GOP sondern Einzelbild-kodiert wie z. B. auch ProRes.

Es ist mir nicht bekannt, dass man HDV nativ (unverändert als MPEG-2) via Firewire einlesen kann (am Mac).

Zum Capturing von DV- oder HDV-Videos gibt's hier ein interessantes Video, und das erste HDV-Beispiel befasst sich mit dem Einlesen (Kamera via QuickTime mit MacBook verbunden - im Beispiel mit 2 Adaptern von Thunderbolt 3 auf Firewire 800) mit QuickTime X - in Qualitätsstufe 'hoch' in AVCHD (also MPEG-4 statt MEPG-2), in Qualitätsstufe 'hoch' in ProRes 4:2:2.
Sieht im YouTube-Vdieo in den QuickTime Infos allerdings so aus, als sei die Vorlage SDV (Standard Definition DV) mit Aspect Ratio 4:3 (statt HDV 16:9).
Falls die Quelle interlaced ist, beachten, ob sie beim Capturen auch interlaced bleibt, falls das gewünscht wird.

Capturing and Archiving MiniDV and HDV Tapes on Mac & Windows - LifeFlix Mini Demo
11. 6. 2021
https://www.youtube.com/watch?v=9L5aaoES1i0

Was Du also an (kostenloser) Software gut gebrauchen kannst (neben QuickTime 7 Pro und X):
remux 1.4 - für Containerwechsel (z.B. MOV nach MP4)
MediaInfo - für detaillierte Infos (in Text- oder HTML-Ansicht) zu Videoclips inkl. Ton - https://sourceforge.net/projects/mediainfo
HandBrake - für ausgewählte Format-Umrechnungen inkl. Datenraten (kbps) / Bildraten (fps)



Antwort von Jott:

„ Es ist mir nicht bekannt, dass man HDV nativ (unverändert als MPEG-2) via Firewire einlesen kann (am Mac).“

Natürlich geht das, ist völlig normal und ja auch der Witz an FireWire, dass die Footage Bit für Bit unverändert vom Band rein kommt. fcp (x) importiert nativ, macht nur einen mov-Wrapper drumrum. Keine Umwandlung. Anschließen und rein damit. Nur früher, vor 2011, wurde nach dem Import automatisch gewandelt für flüssiges Schneiden.

Ging der native Import nicht auch damals schon mit QuickTime X? Weiß nicht mehr, bin kein Software-Historiker. Es gab auch vor 2011 irgendeine freie Capture-Software für Mac, die von manchen benutzt wurde.



Antwort von Skeptiker:

gelöscht



Antwort von Skeptiker:

Sorry, gelöscht - ich kriege das verschachtelte Zitieren im Augenblick nicht hin.

@Jott: Danke für den Hinweis - da lag ich offenbar falsch (keine eigene Erfahrung mit HDV-Import per Firewire, nur DV)!



Antwort von Asjaman:

Danke für eure Infos!

Das hilft mir schon weiter



Antwort von Skeptiker:

@Asjaman:

Gern geschehen.
Eine Frage (aus Interesse, falls Du Zeit hast): Kann man mit QuickTime7 oder QuickTime10 HDV-Video via Firewire nativ capturen (also als MPEG-2 - entweder 720p progressive oder 1080i interlaced) ?

Ein Gedanke: Da MPEG-2 als Codec zugunsten MPEG-4/H.264 heute nur noch wenig verbreitet ist (zumindest, was mobile Anzeigegeräte aller Art betrifft) und man als HDV daraus auch keine DVDs direkt erzeugen kann, stellt sich vielleicht die Frage, ob sich das Capturing in MPEG-2 wirklich lohnt, wenn man später sowieso umrechnet? Fürs Schneiden und Bearbeiten wäre ProRes (mal abgesehen vom Speicher-Mehrverbrauch) flüssiger & geeigneter (mit Mac OS), zum Anschauen MPEG-4 universeller.

Noch ein Gedanke: Spielt die angezeigte, leichte Abweichung des HDV-Capturings mit FCP 7 (nativ in MPEG-2 ?), die Du erwähnst (24.94 fps statt 25 fps), eine entscheidende Rolle für die Weiterverwendbarkeit des Materials?



Antwort von cantsin:

Skeptiker hat geschrieben:
Ein Gedanke: Da MPEG-2 als Codec zugunsten MPEG-4/H.264 heute nur noch wenig verbreitet ist (zumindest, was mobile Anzeigegeräte aller Art betrifft) und man als HDV daraus auch keine DVDs direkt erzeugen kann, stellt sich vielleicht die Frage, ob sich das Capturing in MPEG-2 wirklich lohnt, wenn man später sowieso umrechnet? Fürs Schneiden und Bearbeiten wäre ProRes (mal abgesehen vom Speicher-Mehrverbrauch) flüssiger & geeigneter (mit Mac OS), zum Anschauen MPEG-4 universeller. Jede Umrechnung vermindert die Qualität des Materials. Man sollte IMHO nie das Originalmaterial der Kamera transcodieren und danach wegschmeissen. Das rächt sich spätestens dann, wenn man später z.B. KI-Hochskalierung und -Bildverbesserung macht, die um so besser funktioniert, je weniger das Material nachträglich beeinträchtigt bzw. umgerechnet (und dadurch mit neuen Artefakten versehen) wurde.

Übrigens ist ProRes intern eng mit MPEG-2 verwandt...



Antwort von Jott:

Hallo wowu! :-)






Antwort von Skeptiker:

cantsin hat geschrieben:
Skeptiker hat geschrieben:
Ein Gedanke: Da MPEG-2 als Codec zugunsten MPEG-4/H.264 heute nur noch wenig verbreitet ist (zumindest, was mobile Anzeigegeräte aller Art betrifft) und man als HDV daraus auch keine DVDs direkt erzeugen kann, stellt sich vielleicht die Frage, ob sich das Capturing in MPEG-2 wirklich lohnt, wenn man später sowieso umrechnet? Fürs Schneiden und Bearbeiten wäre ProRes (mal abgesehen vom Speicher-Mehrverbrauch) flüssiger & geeigneter (mit Mac OS), zum Anschauen MPEG-4 universeller. Jede Umrechnung vermindert die Qualität des Materials. Man sollte IMHO nie das Originalmaterial der Kamera transcodieren und danach wegschmeissen. ... Hmm ..
bei DV-Video gab's z. B. die berüchtigten Treppchen (kein Anti-Aliasing) in diagonal verlaufenden Kanten/Linien. Bei ProRes ist mir dieses Problem nicht bekannt (bei MPEG-2 ebenfalls nicht).
Aber generell stimmt Dein erster Einwand (Umrechnung) natürlich - insbesondere für stark ins Bild eingreifendes Neukodieren.
Und auch dem zweiten Hinweis (Originalmaterial behalten) stimme ich zu. Würde nur hinzufügen - es kommt ein wenig darauf an, ..

- Ob das Material privat/spontane Gelegenheitsaufnahmen (wie heute per Smartphone) oder kommerziell ist
- Ob eine Weiterverarbeitung (jetzt oder später) überhaupt geplant ist
- Ob der Capture-Codec das Original-Material stark beeinflusst oder praktisch unverändert belässt
- Wie die weitere Bearbeitung des eingelesen Kameramaterials aussieht und welche Software dafür zur Verfügung steht

Aber für kommerzielle/professionelle Aufnahmen würde ich ebenfalls a) das Material im Originalformat capturen und b) auch die Original-Kassetten noch schonend aufbewahren

Zu den beiden Codecs aus vergangenen Zeiten: DV und MPEG-2 sind heute aus dem Videoalltag praktisch verschwunden (von DVDs einmal abgesehen). Zumindest, was neuere Technik angeht. In TV-Anstalten mag DV/HDV-Technik weltweit noch verbreitet oder teils im Einsatz sein, das kann ich zu wenig beurteilen.
Generell ist Dekodieren (zum Ansehen/Abspielen) noch möglich, aber beim Enkodieren mit diesen Codecs kann es schon schwierig werden.

Wenn ich also HDV im Originalcodec MEPG-2 capture und das Material danach irgendwie bearbeiten will, komme ich ums Neukodieren kaum herum. Entweder, weil mein Editing Programm das MPEG-2 im Hintergrund bereits umkodiert (z.B. in ein All-i Format wie ProRes - früher deshalb als Intermediate Format bezeichnet) oder dann spätestens beim Wieder-Abspeichern, sofern ich nicht ein seltenes Editing Tool verwende, das natives MPEG-2 Editing beherrscht und nur die tatsächlich veränderten Bereiche des Gesamtvideos rendert/neukodiert (sogenanntes Smart-Rendering), bevor es das ganze Video wieder als MPEG-2 mit den Original-Einstellungen abspeichert.
Das relativiert die Bedeutung, im Original-Codec capturen zu müssen, wieder ein wenig.



Antwort von cantsin:

Skeptiker hat geschrieben:
cantsin hat geschrieben:


Jede Umrechnung vermindert die Qualität des Materials. Man sollte IMHO nie das Originalmaterial der Kamera transcodieren und danach wegschmeissen. ... Hmm ..
bei DV-Video gab's z. B. die berüchtigten Treppchen (kein Anti-Aliasing) in diagonal verlaufenden Kanten/Linien. Bei ProRes ist mir dieses Problem nicht bekannt (bei MPEG-2 ebenfalls nicht). Du meinst Interlacing. Dein obiges Beispiel illustriert das Problem perfekt: Beim Uncodieren in ProRes wird i.d.R. ein Deinterlacing gemacht, aber Deinterlacing ist systembedingt eine Heuristik (genau wie Debayering) und geht mit heutigen KI-Algorithmen (z.B. dem Deinterlacing von Topaz AI) qualitativ wesentlich besser/hochwertiger. Wenn Du also Dein HDV oder DV-Material mit dem relativ primitiven Quicktime-Encoder von vor 15 Jahren deinterlact hast, ist dieses Deinterlacing fest eingebacken und verbaust Du Dir die Möglichkeit, das mit moderneren Verfahren besser zu machen.

- Ob das Material privat/spontane Gelegenheitsaufnahmen (wie heute per Smartphone) oder kommerziell ist
- Ob eine Weiterverarbeitung (jetzt oder später) überhaupt geplant ist
- Ob der Capture-Codec das Original-Material stark beeinflusst oder praktisch unverändert belässt
- Wie die weitere Bearbeitung des eingelesen Kameramaterials aussieht und welche Software dafür zur Verfügung steht Da bin ich mir nicht so sicher. Wer seine alten Familienaufnahmen auf DV-Cassetten hat, hat sicher nichts dagegen einzuwenden, wenn man dieses Material mit KI-Software auf HD-Qualität hochrechnet, damit es auch auf dem heutigen 50-Zoll-Wohnzimmer-Flatscreen-TV ansehnlich aussieht.

Zu den beiden Codecs aus vergangenen Zeiten: DV und MPEG-2 sind heute aus dem Videoalltag praktisch verschwunden (von DVDs einmal abgesehen). Zumindest, was neuere Technik angeht. In TV-Anstalten mag DV/HDV-Technik weltweit noch verbreitet oder teils im Einsatz sein, das kann ich zu wenig beurteilen.
Generell ist Dekodieren (zum Ansehen/Abspielen) noch möglich, aber beim Enkodieren mit diesen Codecs kann es schon schwierig werden. Nein. ffmpeg und diverse darauf aufsetzende Tools können Dir problemlos DV und MPEG encodieren.
Wenn ich also HDV im Originalcodec MEPG-2 capture und das Material danach irgendwie bearbeiten will, komme ich ums Neukodieren kaum herum. Nein, im Gegenteil - MPEG-2 flutscht prima in heutigen NLEs.
Entweder, weil mein Editing Programm das MPEG-2 im Hintergrund bereits umkodiert (z.B. in ein All-i Format wie ProRes - früher deshalb als Intermediate Format bezeichnet) Das war der Stand der Technik von vor ungefähr 10-15 Jahren. Heute arbeiten praktisch alle NLEs (Premiere, Resolve, FCP) mit den nativen Codecs, es sei denn, man weist sie explizit an, Proxies zu erzeugen.



Antwort von dienstag_01:

cantsin hat geschrieben:
Skeptiker hat geschrieben:


Hmm ..
bei DV-Video gab's z. B. die berüchtigten Treppchen (kein Anti-Aliasing) in diagonal verlaufenden Kanten/Linien. Bei ProRes ist mir dieses Problem nicht bekannt (bei MPEG-2 ebenfalls nicht). Du meinst Interlacing. Dein obiges Beispiel illustriert das Problem perfekt: Beim Uncodieren in ProRes wird i.d.R. ein Deinterlacing gemacht, aber Deinterlacing ist systembedingt eine Heuristik (genau wie Debayering) und geht mit heutigen KI-Algorithmen (z.B. dem Deinterlacing von Topaz AI) qualitativ wesentlich besser/hochwertiger. Wenn Du also Dein HDV oder DV-Material mit dem relativ primitiven Quicktime-Encoder von vor 15 Jahren deinterlact hast, ist dieses Deinterlacing fest eingebacken und verbaust Du Dir die Möglichkeit, das mit moderneren Verfahren besser zu machen.

- Ob das Material privat/spontane Gelegenheitsaufnahmen (wie heute per Smartphone) oder kommerziell ist
- Ob eine Weiterverarbeitung (jetzt oder später) überhaupt geplant ist
- Ob der Capture-Codec das Original-Material stark beeinflusst oder praktisch unverändert belässt
- Wie die weitere Bearbeitung des eingelesen Kameramaterials aussieht und welche Software dafür zur Verfügung steht Da bin ich mir nicht so sicher. Wer seine alten Familienaufnahmen auf DV-Cassetten hat, hat sicher nichts dagegen einzuwenden, wenn man dieses Material mit KI-Software auf HD-Qualität hochrechnet, damit es auch auf dem heutigen 50-Zoll-Wohnzimmer-Flatscreen-TV ansehnlich aussieht.

Zu den beiden Codecs aus vergangenen Zeiten: DV und MPEG-2 sind heute aus dem Videoalltag praktisch verschwunden (von DVDs einmal abgesehen). Zumindest, was neuere Technik angeht. In TV-Anstalten mag DV/HDV-Technik weltweit noch verbreitet oder teils im Einsatz sein, das kann ich zu wenig beurteilen.
Generell ist Dekodieren (zum Ansehen/Abspielen) noch möglich, aber beim Enkodieren mit diesen Codecs kann es schon schwierig werden. Nein. ffmpeg und diverse darauf aufsetzende Tools können Dir problemlos DV und MPEG encodieren.
Wenn ich also HDV im Originalcodec MEPG-2 capture und das Material danach irgendwie bearbeiten will, komme ich ums Neukodieren kaum herum. Nein, im Gegenteil - MPEG-2 flutscht prima in heutigen NLEs.
Entweder, weil mein Editing Programm das MPEG-2 im Hintergrund bereits umkodiert (z.B. in ein All-i Format wie ProRes - früher deshalb als Intermediate Format bezeichnet) Das war der Stand der Technik von vor ungefähr 10-15 Jahren. Heute arbeiten praktisch alle NLEs (Premiere, Resolve, FCP) mit den nativen Codecs, es sei denn, man weist sie explizit an, Proxies zu erzeugen. "Beim Umkodieren in ProRes wird i.d.R ein Deinterlacing gemacht." Bestimmt. Weil sowas ja der Codec entscheidet ;)



Antwort von R S K:

dienstag_01 hat geschrieben:
Weil sowas ja der Codec entscheidet ;) Genau. Natürlich nicht. Weshalb das auch Unsinn ist.



Antwort von Jott:

cantsin hat geschrieben:
Das war der Stand der Technik von vor ungefähr 10-15 Jahren. Den Stand haben erstaunlicherweise einige der Diskutanten hier in diesem Thread.



Antwort von Skeptiker:

cantsin hat geschrieben:
Skeptiker hat geschrieben:


Hmm ..
bei DV-Video gab's z. B. die berüchtigten Treppchen (kein Anti-Aliasing) in diagonal verlaufenden Kanten/Linien. Bei ProRes ist mir dieses Problem nicht bekannt (bei MPEG-2 ebenfalls nicht). Du meinst Interlacing. Dein obiges Beispiel illustriert das Problem perfekt: Beim Uncodieren in ProRes wird i.d.R. ein Deinterlacing gemacht, ... Nein, ich dachte nicht an die "Sägezähne" beim Interlacing.
'Standard Definition'-Spezialist Goldwingfahrer, als er hier noch aktiv war, erwähnte das Problem immer mal wieder in seinen Beiträgen, wenn es um den DV Codec (und ums Capturing damit) ging, von dem er kein grosser Fan war.
Und ich kenne das Problem aus eigener DV-Erfahrung (aber damals war man trotzdem begeistert von der digitalen Videoqualität im Vergleich zu analog).

Und ProRes kann ja auch interlaced sein - kein Zwang zum De-Interlacing.
cantsin hat geschrieben:
Skeptiker hat geschrieben:
- Ob das Material privat/spontane Gelegenheitsaufnahmen (wie heute per Smartphone) oder kommerziell ist
- Ob eine Weiterverarbeitung (jetzt oder später) überhaupt geplant ist
- Ob der Capture-Codec das Original-Material stark beeinflusst oder praktisch unverändert belässt
- Wie die weitere Bearbeitung des eingelesen Kameramaterials aussieht und welche Software dafür zur Verfügung steht Da bin ich mir nicht so sicher. Wer seine alten Familienaufnahmen auf DV-Cassetten hat, hat sicher nichts dagegen einzuwenden, wenn man dieses Material mit KI-Software auf HD-Qualität hochrechnet, damit es auch auf dem heutigen 50-Zoll-Wohnzimmer-Flatscreen-TV ansehnlich aussieht. Das stimmt, und es ist erfreulich, dass es möglich ist. Aber vor dem Upscaling muss das Video ja bearbeitet werden, und das geht nicht in Topaz.
cantsin hat geschrieben:
Skeptiker hat geschrieben:
Zu den beiden Codecs aus vergangenen Zeiten: DV und MPEG-2 sind heute aus dem Videoalltag praktisch verschwunden (von DVDs einmal abgesehen). Zumindest, was neuere Technik angeht. In TV-Anstalten mag DV/HDV-Technik weltweit noch verbreitet oder teils im Einsatz sein, das kann ich zu wenig beurteilen.
Generell ist Dekodieren (zum Ansehen/Abspielen) noch möglich, aber beim Enkodieren mit diesen Codecs kann es schon schwierig werden. Nein. ffmpeg und diverse darauf aufsetzende Tools können Dir problemlos DV und MPEG encodieren. Aber nicht aus allen kommerziellen/professionellen Editing-Programmen heraus. Womit evtl. ein Zwischenspeichern nötig ist, wenn ich das Video anderswo weiterbearbeiten will.
cantsin hat geschrieben:
Skeptiker hat geschrieben:
Wenn ich also HDV im Originalcodec MEPG-2 capture und das Material danach irgendwie bearbeiten will, komme ich ums Neukodieren kaum herum. Nein, im Gegenteil - MPEG-2 flutscht prima in heutigen NLEs. Und speichert am Ende in welchem Format "smart" wieder ab, ohne alles neu zu kodieren?
cantsin hat geschrieben:
Das war der Stand der Technik von vor ungefähr 10-15 Jahren. Heute arbeiten praktisch alle NLEs (Premiere, Resolve, FCP) mit den nativen Codecs, es sei denn, man weist sie explizit an, Proxies zu erzeugen. Wenn es tatsächlich so ist, speichern sie auch in den nativen Codecs mit unveränderten Einstellungen wieder ab (siehe mein Einwand oben)?
Wenn Letzteres nicht der Fall ist, dann wäre so ein Codec wie ProRes (vor allem auf dem Mac) durchaus im Editing-Vorteil (und damit vielleicht auch bereits im Capture-Vorteil), der früher damit warb, dass er zwar (technisch) nicht lossless sei (wie z.B. eine ZIP-Kompression für beliebige Dateien), aber "visually lossless" (für die höheren Qualitätsstufen) über mehrere Abspeicher-Generationen. Wenn ich also bei meiner Bearbeitungs-Rundreise über verschiedene Programm-Stationen gehe/gehen muss (die ProRes editieren und auch abspeichern können), habe ich am Ende vermutlich weniger Bildqualitätsverluste, als wenn ich unbedingt bis kurz vors oder ans Ende in DV oder MPEG-2 bleiben will und auf dem Weg dorthin Formatwechsel in Kauf nehmen muss.



Antwort von Skeptiker:

Jott hat geschrieben:
cantsin hat geschrieben:
Das war der Stand der Technik von vor ungefähr 10-15 Jahren. Den Stand haben erstaunlicherweise einige der Diskutanten hier in diesem Thread. Na ja, das liegt nicht zuletzt an der Art des Problems, das der Fragesteller hier aufwirft.



Antwort von Darth Schneider:

Ich hatte meine ganzen hdv/dv Bänder mit meinem alten iMac (vor letzte Generation) wo noch eine uralte Version von Final Cut darauf installiert ist digitalisiert. (Ich glaube das war nativ, bin mir aber nicht sicher)
Dann hab ich das wichtige Zeugs auf BluRay beziehungsweise auch auf DVDs kopiert. Und die Orignal Files die ich behalten wollte auf eine Hdd kopiert.
Bearbeitet hab ich das aber alles gleich auch auf dem alten iMac mit dem Final Cut.
Gruss Boris



Antwort von R S K:

Das Video von Skeptiker erklärt doch bestens wie man es machen kann. Mehr muss man doch gar nicht wissen. Kann man alles hervorragend mit neuster Hard- UND Software machen. Nativ DV sogar mit Szenenerkennung. Was will man denn mehr?






Antwort von Darth Schneider:

Klar, aber damals als ich das gemacht hatte kannte ich das Video vom Skeptiker noch nicht..
Nur eine weitere Möglichkeit wie das halt auch geht.
Alte Versionen von Final Cut findet man bestimmt noch im Netz..
Und alte iMacs haben auch so manche womöglich immer noch Zuhause herumstehen…

Und so konnte man auch gleich alles zusammen ganz einfach in der einen selben Software erledigen.
Gruss Boris



Antwort von Jott:

Alle neuen Macs können das alles immer noch, da muss man keine Oldtimer bemühen. Es sei denn, die Thunderbolt-zu-Firewire-Adapter findet man zu teuer.

Bei fcp kann‘s nicht am Preis liegen, das ist lange genug kostenlos, um die alten Cassetten gemütlich einzuspielen.



Antwort von Darth Schneider:

Ja aber die Oldtimer von Final Cut laufen doch gar nicht auf den neuen iMacs.
Und ausserdem wenn sie dort auf den alten Kisten schon eh installiert sind, und seit Jahren zuverlässig funktionieren, was spricht dann dagegen ?
Und z.B. Disks brennen können die neuen Versionen doch auch nicht mehr,
oder doch ?
Und ein Kabel Adapter braucht es zumindest bei machen alten HDV Cameras so oder so…;)
Gruss Boris



Antwort von Jott:

Mit Oldtimer meinte ich Hardware. Aber klar, auch mit einem 15 Jahre alten Gesamtsystem kann man problemlos HDV einlesen. Ging mit fcp 4 (?) schon 2004 oder 2005. Als HDV auf den Markt kam halt.



Antwort von Asjaman:

Ich habe nun doch das alte FCP7 bemüht und testweise eine HDV Cassette eingelesen.
Brav legt das Programm für jede erkannte Szene eine mov Datei an, natürlich interlaced.
Diese kann ich später direkt in Resolve laden. Wenn man hier in den Einstellungen für Image scaling / deinterlacen den Wert „high“ wählt, reicht mir das an Qualität.

Die Framerate liegt zum Glück konstant bei 25 fps. Damals hatte ich einen Haufen mit FCP eingelesener DV Dateien erhalten, die oftmals abweichende Framerates aufwiesen, was dann im Media Composer zu Problemen führte und ich eine Umrechnung auf konstante 25 fps vornehmen musste. Später las ich in irgendeinem Forum von dem Bug in FCP, an Details erinnere ich mich aber nicht mehr.

Sehr interessante Ausführungen hier, danke nochmal!



Antwort von Jott:

Asjaman hat geschrieben:
Später las ich in irgendeinem Forum von dem Bug in FCP, an Details erinnere ich mich aber nicht mehr. In Foren wird viel Unsinn geschrieben. Gut, dass alles klappt, wie zu erwarten. Freu dich!



Antwort von R S K:

Jott hat geschrieben:
In Foren wird viel Unsinn geschrieben. WAAAAAS??

😜



Antwort von Skeptiker:

Asjaman hat geschrieben:
Ich habe nun doch das alte FCP7 bemüht und testweise eine HDV Cassette eingelesen.
Brav legt das Programm für jede erkannte Szene eine mov Datei an, natürlich interlaced.
Diese kann ich später direkt in Resolve laden. Wenn man hier in den Einstellungen für Image scaling / deinterlacen den Wert „high“ wählt, reicht mir das an Qualität.

Die Framerate liegt zum Glück konstant bei 25 fps. Damals hatte ich einen Haufen mit FCP eingelesener DV Dateien erhalten, die oftmals abweichende Framerates aufwiesen, was dann im Media Composer zu Problemen führte und ich eine Umrechnung auf konstante 25 fps vornehmen musste. Später las ich in irgendeinem Forum von dem Bug in FCP, an Details erinnere ich mich aber nicht mehr.

Sehr interessante Ausführungen hier, danke nochmal! Hallo Asjaman,

Freut mich ebenfalls, wenn es jetzt auch mit dem alten FCP 7 funktioniert (das schliesslich aus der DV/HDV-Zeit stammt)!
Falls Du hier nochmals vorbeischaust, würde ich gerne erneut nachfragen (Verzeihung, wenn ich da etwas hartnäckig bin, aber ich lerne gerne auch dazu und habe mit HDV-Bändern keine eigene Erfahrung):

a) In welchem Format wurde die HDV-Kassette in FCP 7 eingelesen? Original MPEG-2, interlaced (welche Datenrate?) oder evtl. ProRes?

Falls das in FCP 7 nicht klar angezeigt wird (bzw. spontan auffindbar ist), wird es auf jeden Fall mit MediaInfo erkannt.

b) Lässt sich mit QuickTime 7 Pro (die Pro-Version ist bei installiertem FCP 7 immer vorhanden) oder QuickTime X eine HDV-Kassette im Original-Format (also MPEG-2, wohl als .mov verpackt) capturen ? Falls ja, vermutlich am Stück, ohne Szenenerkennung. Mit welcher Datenrate?
Mit QuickTime X und mit Qualitäts-Auswahl "maximal" im Capture-Fenster (dazu kleines Dreieck anklicken rechts neben dem roten Record-Knopf) müsste im ProRes-Format eingelesen werden (interlaced bei entsprechender Quelle) - stimmt das?

Gruss
Skeptiker



Antwort von Jott:

1:1 vom Band, also Original MPEG 2. Und natürlich interlaced, wenn die Aufnahme interlaced war.

Und natürlich mit Original-Datenrate (25Mbit/s).

Was QuickTime gemacht hatte, weiß ich nicht. „Höchste Qualität“ wäre irreführend, denn das Original hat die höchste Qualität.

Da fcp 7 für Broadcast ausgelegt war, ist MPEG 2 dessen Leib- und Magencodec, so wie XDCAM.






Antwort von Skeptiker:

@Jott:
Danke für den Hinweis.

So kommt Oldie FCP 7 frisch aus dem Altersheim doch nochmals zu späten Ehren! ;-)

Vielleicht meldet sich der Fragesteller ja noch zum HDV-Capturing mit QuickTime.

Wenn FCP 7 nicht installiert ist, fehlt die QuickTime7-Systemerweiterung QuickTimeMPEG2.component (die man bei Apple dazukaufen konnte), ohne die meines Wissens MPEG-2 mit QuickTime 7 (auch 'Pro') weder abgespielt noch kodiert werden kann.

QuickTime X öffnet in meinem macOS 10.14.6 (ohne FCP 7) hingegen ein MPEG-2-File zum Abspielen. Und mit VLC Player geht's natürlich auch (dank hinterlegtem FFmpeg).



Antwort von Jott:

Diese kostenpflichtige MPEG 2-Erweiterung (20 Euro) war kein feiner Zug von Apple. Ist aber 12 Jahre her - jetzt kommt's drauf an, wie nachtragend man sein möchte! :-)



Antwort von Skeptiker:

Jott hat geschrieben:
Diese kostenpflichtige MPEG 2-Erweiterung (20 Euro) war kein feiner Zug von Apple. Ist aber 12 Jahre her - jetzt kommt's drauf an, wie nachtragend man sein möchte! :-) Ich bin's als FCP7-Besitzer nicht! ;-)
Und die Kosten dafür waren auch den Lizenzgebühren geschuldet, die das MPEG-2-Konsortium (hiess das so?) erhob (und noch immer erhebt?).



Antwort von Asjaman:

Skeptiker hat geschrieben:

a) In welchem Format wurde die HDV-Kassette in FCP 7 eingelesen? Original MPEG-2, interlaced (welche Datenrate?) oder evtl. ProRes? Hallo Skeptiker,

zumindest zum Format der aufgenommenen Clips kann ich dir schonmal etwas sagen bzw. die Textwüste von MediaInfo kopieren. Bitte bedienen Sie sich:

General
Complete name : I:\Unbenannt-15.mov
Format : MPEG-4
Commercial name : HDV 1080i
Format profile : QuickTime
Codec ID : qt 2005.03 (qt )
File size : 46.0 MiB
Duration : 14 s 360 ms
Overall bit rate : 26.9 Mb/s
Encoded date : UTC 2023-03-21 11:28:47
Tagged date : UTC 2023-03-21 11:28:47
Writing library : Apple QuickTime
Media/UUID : 8455F08E-453A-446B-999E-B5CA3C337831

Video
ID : 1
Format : MPEG Video
Commercial name : HDV 1080i
Format version : Version 2
Format profile : Main@High 1440
Format settings : CustomMatrix / BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Format settings, picture structure : Frame
Codec ID : hdv3
Duration : 14 s 360 ms
Source duration : 14 s 520 ms
Bit rate mode : Constant
Bit rate : 25.0 Mb/s
Width : 1 440 pixels
Clean aperture width : 1 416 pixels
Height : 1 080 pixels
Clean aperture height : 1 062 pixels
Display aspect ratio : 16:9
Clean aperture display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Interleaved fields
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.643
Stream size : 42.8 MiB (93%)
Source stream size : 43.3 MiB (94%)
Title : Apple Video Mediensteuerung / Apple Alias-Datensteuerung
Language : English
Encoded date : UTC 2023-03-21 11:28:47
Tagged date : UTC 2023-03-21 11:28:47
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio #1
ID : 2
Format : PCM
Format settings : Little / Signed
Codec ID : sowt
Duration : 14 s 360 ms
Source duration : 14 s 544 ms
Bit rate mode : Constant
Bit rate : 768 kb/s
Channel(s) : 1 channel
Channel layout : L
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 1.31 MiB (3%)
Source stream size : 1.33 MiB (3%)
Title : Apple Ton Mediensteuerung / Apple Alias-Datensteuerung
Language : English
Encoded date : UTC 2023-03-21 11:28:47
Tagged date : UTC 2023-03-21 11:28:47

Audio #2
ID : 3
Format : PCM
Format settings : Little / Signed
Codec ID : sowt
Duration : 14 s 360 ms
Source duration : 14 s 544 ms
Bit rate mode : Constant
Bit rate : 768 kb/s
Channel(s) : 1 channel
Channel layout : R
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 1.31 MiB (3%)
Source stream size : 1.33 MiB (3%)
Title : Apple Ton Mediensteuerung / Apple Alias-Datensteuerung
Language : English
Encoded date : UTC 2023-03-21 11:28:47
Tagged date : UTC 2023-03-21 11:28:47

Other
ID : 4
Type : Time code
Format : QuickTime TC
Duration : 14 s 360 ms
Frame rate : 25.000 FPS
Time code of first frame : 00:03:46:12
Time code, striped : Yes
Title : Zeitmarken-Mediensteuerung / Apple Alias-Datensteuerung / Erhardt 20080428
Language : English
Default : No
Encoded date : UTC 2023-03-21 11:28:47
Tagged date : UTC 2023-03-21 11:28:47



Antwort von R S K:

Jott hat geschrieben:
Diese kostenpflichtige MPEG 2-Erweiterung (20 Euro) war kein feiner Zug von Apple. Wohl eher die Lizenzgebühren der Moving Picture Experts Group.



Antwort von Skeptiker:

Hallo Asjaman,

Vielen Dank für die umfangreiche Liste! :-)

Ich picke mal das Wesentliche heraus:

a) Es geht um den HDV-Import mit FCP 7 (nicht QuickTime 7 oder 10)
b) Das Format ist das Original-Format MPEG-2, und zwar 1080 x 1440i, also interlaced
c) die Video-Datenrate entspricht dem HDV2-Standard von 25 Megabit/Sekunde (Mbit/s)
d) Die Bildrate entspricht mit 25 fps (frames per second) dem PAL-Standard, interlaced sind es dann 50 Halbbilder (fields) pro Sekunde.
e) Der Ton ist speziell - nämlich 1-kanalig (nicht Stereo) und unkomprimiert (PCM) mit 48 kHz (CD Audio wäre 44 kHz).
Standard Audio-Kompression bei HDV ist sonst MPEG-2 Audio, Layer 2 (Layer 3 wäre das als Nur-Audio verbreitete mp3 - kann auch MPEG-1 Audio, Layer 3 sein).
MPEG-2 Audio hat technisch nichts mit MPEG-2 Video zu tun.

Fazit: Das ist offensichtlich ein 1:1-Capturing der digitalen Aufnahmen auf dem Kameraband.

Wenn Du einmal Zeit findest, kannst Du vielleicht auch den HDV-Import mit QuickTime 7 / QuickTime 10 noch probieren (ein kurzes Bandstück genügt ja). Es wäre interessant zu wissen, ob das in maximaler Qualität (einstellbar im QuickTime-Aufnahme-Fenster nach Klick auf das kleine Dreieck beim roten Record-Knopf) im Original-Format passiert oder umgewandelt nach ProRes.



Antwort von Jott:

„Der Ton ist speziell - nämlich 1-kanalig (nicht Stereo)“

Woher hast du nur immer solchen Mumpitz?



Antwort von Skeptiker:

Jott hat geschrieben:
„Der Ton ist speziell - nämlich 1-kanalig (nicht Stereo)“

Woher hast du nur immer solchen Mumpitz? Damit Du ihn korrigieren kannst!

Aber im Ernst:
1-Kanal ist Standard?
Oder werden die Audio-Kanäle in MediaInfo links/rechts getrennt angezeigt? (wäre mir neu)!

Mit der Bitte um Erleuchtung!



Antwort von Jott:

Ganz normales Format mit zwei ganz normalen Tonspuren.






Antwort von Skeptiker:

Jott hat geschrieben:
Ganz normales Format mit zwei ganz normalen Tonspuren. Die aber auch 2 Sterospuren sein könnten (Audio 1 und Audio 2) ?

Hier ist es also z. B. ein Interview mit 2 Ansteckmikrofonen.



Antwort von Asjaman:

Hallo!

Gemäß den Daten von MediaInfo ist das Audio der MOV Dateien zweikanalig, einmal links und einmal rechts (L/R). Ich bin eigentlich froh, wenn Stereo- Aufnahmen zur Bearbeitung wie hier als Dual Mono vorliegen statt als Stereo Datei, weil man so das Panorama besser einstellen kann.

PS Ich vermisse bei Resolve diese Funktion vom Media Composer für Stereo-Dateien: Split to Mono



Antwort von Skeptiker:

Asjaman hat geschrieben:
Hallo!

Gemäß den Daten von MediaInfo ist das Audio der MOV Dateien zweikanalig, einmal links und einmal rechts (L/R). Ich bin eigentlich froh, wenn Stereo- Aufnahmen zur Bearbeitung wie hier als Dual Mono vorliegen statt als Stereo Datei, weil man so das Panorama besser einstellen kann. Dann konnte die Kamera falls nötig auch 4 Audiospuren aufnehmen (Audio 1 Stereo und Audio 2 Stereo) ??

Bei DV war's ja so, dass man Stereo aufnehmen konnte (Audio 1 mit 16 bit/48 kHz) und nachträglich Stereo nachvertonen konnte (aufs Band - Audio2), dann nur mit 12 bit/32 kHz, wenn ich mich recht erinnere.



Antwort von Asjaman:

Dann konnte die Kamera falls nötig auch 4 Audiospuren aufnehmen (Audio 1 Stereo und Audio 2 Stereo) ?? Bei den damaligen HDV Henkelmännern (Canon und Sony) waren 4 Tonspuren durchaus machbar.
Aber das ist, glaube ich, unabhängig von der Frage, warum FCP7 in der mov Datei die Stereoaufnahme als zwei getrennte Spuren anlegt.



Antwort von Skeptiker:

Asjaman hat geschrieben:
Dann konnte die Kamera falls nötig auch 4 Audiospuren aufnehmen (Audio 1 Stereo und Audio 2 Stereo) ?? Bei den damaligen HDV Henkelmännern (Canon und Sony) waren 4 Tonspuren durchaus machbar.
Aber das ist, glaube ich, unabhängig von der Frage, warum FCP7 in der mov Datei die Stereoaufnahme als zwei getrennte Spuren anlegt. Das hat mich eben auch in Deinem MediaInfo-Text gewundert, wo es für mich mit Audio 1 (1-Kanal) und Audio 2 (1-Kanal) eher so aussieht, als seien es 2 Monospuren.

Oder bringe ich jetzt Kanäle (Ton-Eingänge: links/rechts) und (Aufnahme-)Spuren (auf dem Band) durcheinander ?

Ich habe gerade ein altes DV-.mov angeschaut, das sieht in MediaInfo so aus:

Audio #1
ID : 1
Format : PCM
Format settings : Big / Signed
Codec ID : twos
Duration : 7 s 240 ms
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 1.33 MiB (5%)
Title : Apple Ton Mediensteuerung / Apple Alias-Datensteuerung
Language : English
Encoded date : UTC 2002-10-16 15:52:40
Tagged date : UTC 2003-07-05 11:06:44

Audio #2
ID : 3-0
Format : PCM
Format settings : Big / Signed
Muxing mode : DV
Muxing mode, more info : Muxed in Video #1
Duration : 7 s 240 ms
Bit rate mode : Constant
Bit rate : 768 kb/s
Channel(s) : 2 channels
Sampling rate : 32.0 kHz
Bit depth : 12 bits
Stream size : 679 KiB (3%)

Audio #3
ID : 3-1
Format : PCM
Format settings : Big / Signed
Muxing mode : DV
Muxing mode, more info : Muxed in Video #1
Duration : 7 s 240 ms
Bit rate mode : Constant
Bit rate : 768 kb/s
Channel(s) : 2 channels
Sampling rate : 32.0 kHz
Bit depth : 12 bits
Stream size : 679 KiB (3%)

Die eigentlichen DV-Tonspuren sind anscheinend Audio 1 (2-Kanal mit 16 bit/48 kHz) und entweder Audio 2 oder Audio 3 (beide 2-Kanal, aber nur 12 bit/32 kHz, also hier die leere Nachvertonungs-Spur)

Warum die Nachvertonungsspur in MediaInfo 2x aufgelistet wird (Audio 2 und Audio 3), weiss ich nicht, auf dem DV-Band ist sie meines Wissens nur einmal vorhanden.



Antwort von Asjaman:

Skeptiker hat geschrieben:
QuickTime 7 Pro (die Pro-Version ist bei installiertem FCP 7 immer vorhanden) Ich kenne die Eingeweide meines alten iMacs nicht besonders gut (ich war immer schon ein Windows-Nutzer). Jedenfalls ist es mir nicht gelungen, Quicktime 7 Pro zu entdecken, trotz komplett installiertem FCP7. Im iMac Programm Ordner befindet sich der Quicktime Player, das ist schon alles, was sich Quicktime schimpft.



Antwort von Bluboy:

Quicktime-Player ist schon der halbe weg



Antwort von Skeptiker:

Asjaman hat geschrieben:
Skeptiker hat geschrieben:
QuickTime 7 Pro (die Pro-Version ist bei installiertem FCP 7 immer vorhanden) Ich kenne die Eingeweide meines alten iMacs nicht besonders gut (ich war immer schon ein Windows-Nutzer). Jedenfalls ist es mir nicht gelungen, Quicktime 7 Pro zu entdecken, trotz komplett installiertem FCP7. Im iMac Programm Ordner befindet sich der Quicktime Player, das ist schon alles, was sich Quicktime schimpft. Hallo Asjaman,

Neben der Suche danach gibt es noch 2 Möglichkeiten:
a) Im Ordner Dienstprogramme (innerhalb des Programmordners) nachsehen
b) Auf ein .mov (DV-mov) klicken mit rechter Maustaste: Öffnet das Kontext-Menü, dort 'Öffnen mit ...' auswählen

Wenn Du ihn gefunden und die Kamera angeschlossen hast, kannst Du die Videoquelle links oben im Menü QuickTime 7 / Einstellungen / Aufnahme auswählen. Dort lässt sich als Qualitätsstufe auch Natives Gerät auswählen.
Die Aufnahme dann starten im Menü Ablage / Neue Video-Aufnahme.

Gruss
Skeptiker



Antwort von Jott:

Also wenn man nicht so recht weiß, was Mono und Stereo eigentlich ist, wird’s schwierig. Hat auch nichts mit HDV zu tun.

Zwei Tonspuren. 1 und 2.
Getrennte Quellen aufnehmen mit zwei Mikros, zum Beispiel zwei Personen im Gespräch.
Oder Stereo aufnehmen mit einem Stereomikro, was dann natürlich beide Spuren belegt.

Es gab sehr exotische HDV-Geräte im teuren Profibereich, die tatsächlich vier Spuren hatten. Aber das ist eine homöopathische Randerscheinung.


„Aber das ist, glaube ich, unabhängig von der Frage, warum FCP7 in der mov Datei die Stereoaufnahme als zwei getrennte Spuren anlegt.“

Völlig normal. Sind doch zwei Spuren!






Antwort von Asjaman:

Jott hat geschrieben:
„Aber das ist, glaube ich, unabhängig von der Frage, warum FCP7 in der mov Datei die Stereoaufnahme als zwei getrennte Spuren anlegt.“

Völlig normal. Sind doch zwei Spuren! Ich bestreite ja gar nicht, dass das normal ist. Aber ebenso normal ist, dass eine Audiodatei im Header als "stereo" definiert wird, also 2-kanalig, und das sind dann eben nicht "getrennte" Spuren im Sinne von einzeln angelegt.
Zum damals von mir genutzten Prosumer Camcorder Sony HVR-Z5 gab es zum Andocken einen kleinen Digitalrecorder, der das native HDV-Signal parallel zur Kassette auf CF Karten speicherte. Schaut man sich diese m2t Dateien in MediaInfo an, steht dort für die eine aufgenommene MPEG1-Layer2 Audiospur "2 channels"



Antwort von Jott:

Oh Leute …

„also 2-kanalig, und das sind dann eben nicht "getrennte" Spuren im Sinne von einzeln angelegt.“

Zwei getrennte Spuren sind immer zwei getrennte Spuren. Die Kamera kann gar nicht wissen, ob das zwei Monosignale sein sollen oder eine Stereoaufnahme. Wissen kannst das nur du. Also der Mensch, der die Aufnahme gemacht hat.

Ich wüßte auch nicht, wieso das zu Ratespielen führt. Man hört‘s doch eindeutig?



Antwort von R S K:

Jott hat geschrieben:
Oh Leute … 😂

Ich weiß auch nicht, warum manche wirklich nicht verstehen, dass EINE Stereospur logischerweise aus ZWEI Kanälen besteht. Und das seit 1933. Genauso wie eine Surround-Spur aus (mindestens) sechs Kanälen besteht! Diese wiederum können ganz simpel, mit einem Klick (zumindest in Final Cut Pro) in Dual (oder mehr) Mono-Spuren umgewandelt werden.


zum Bild


Ich verstehe auch nicht, was daran so kompliziert und verwirrend sein soll. 🤨

Und keine Ahnung warum das z.B. in Resolve (bzw. nur mit Hilfe von Fairlight?) im Vergleich dazu scheinbar völlig bizarr umständlich ist.



Wow.



Antwort von Asjaman:

"R S K" hat geschrieben:
dass EINE Stereospur logischerweise aus ZWEI Kanälen besteht. Aber klar. Es ging einzig um die Frage, was MediaInfo dazu veranlasst, ein Stereo-Audio in einer Datei als
Audio #1
ID: 2
Channel(s) : 2 channels

und in der anderen Datei als

Audio #1
ID: 2
Channel(s) : 1 channel
Channel layout : L

Audio #2
ID : 3
Channel(s) : 1 channel
Channel layout : R

anzuzeigen. So meinte ich "im Sinne von einzeln angelegt".

Wir müssen hier keine Wortklauberei betreiben. Ich weiß auch, dass die beiden Kanäle in einer Stereo-Spur getrennt sind.



Antwort von MK:

Asjaman hat geschrieben:
Ich bin eigentlich froh, wenn Stereo- Aufnahmen zur Bearbeitung wie hier als Dual Mono vorliegen statt als Stereo Datei, weil man so das Panorama besser einstellen kann. Bei Stereo kann man das Panorama nicht gut einstellen? Oh mei...



Antwort von Asjaman:

MK hat geschrieben:
Asjaman hat geschrieben:
Ich bin eigentlich froh, wenn Stereo- Aufnahmen zur Bearbeitung wie hier als Dual Mono vorliegen statt als Stereo Datei, weil man so das Panorama besser einstellen kann. Bei Stereo kann man das Panorama nicht gut einstellen? Oh mei... 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 und diese jeweils in Richtung Mitte pannen möchte, braucht es erst einen Workaround, der umständlich ist (siehe das von RSK verlinkte Video zu Resolve)
Wenn im Video die Audiokanäle einzeln als Mono 1 (L) und Mono 2 (R) vorliegen, werden gleich zwei Spuren in der Timeline belegt, die ich sofort pannen kann.

Oder was war deine Frage?



Antwort von pillepalle:

Pssst... nicht verraten das man Stereoaufnahmen (mit Ausnahme von matrizierten MS) gar nicht pannt. Die sind immer hart links und hart rechts. Aber machen kann man mit seiner Aufnahme prinzipiell natürlich alles.

VG



Antwort von cantsin:

Asjaman hat geschrieben:
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 und diese jeweils in Richtung Mitte pannen möchte, braucht es erst einen Workaround, der umständlich ist (siehe das von RSK verlinkte Video zu Resolve) In Resolve: Einfach auf den Audiotrack gehen und per Rechtsklick "Convert to Linked Group" wählen. Dann kriegst Du zwei Mono-Tracks, die Du unabhängig voneinander pannen kannst.



Antwort von Skeptiker:

Bin auch zurück, mit einem Testergebnis:

Habe über Mittag mit QuickTime ein DV-Capturing per Firewire gemacht.
Der Ton ist PCM Stereo und wird als Audio1: '2 channels', 48 kHz/16 bit in MediaInfo angezeigt.
Ich schrieb zuvor etwas von einer zusätzlichen 32kHz/12bit Nachvertonungsspur für DV.
Das ist wohl keine Nachvertonungsspur, sondern es kann für die Aufnahme zwischen 2-Kanal 48/16 oder 4-Kanal 32/12 gewählt werden (die Gesamt-Datenrate bleibt gleich).

Beim Capture-Test ging es eher um Video (alle Angaben nur für Video, aus MediaInfoLib v19.09)

Mac OS 10.8.5
QuickTime 7.6.6 - Einstellung: Nativ -> DV 24.4 Mbit/s - interlaced
QuickTime 10.2 - Einstellung: Maximale Qualität -> DV 24.4 Mbit/s - interlaced

Mac OS 10.14.6
QuickTime 7.6.6 - Einstellung: Nativ -> DV 24.4 Mbit/s - interlaced
QuickTime 10.5 - Einstellung: Maximale Qualität -> ProRes 40.3 Mbit/s - progressive

Die Video-Abmessungen werden jeweils mit 720*576 (4:3) angegeben, ausser bei ProRes mit 702*576 (4:3).
Beim Öffnen mit QuickTime (7 oder 10) ist aber kein Grössen-Unterschied erkennbar.






Antwort von Asjaman:

cantsin hat geschrieben:
Asjaman hat geschrieben:
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 und diese jeweils in Richtung Mitte pannen möchte, braucht es erst einen Workaround, der umständlich ist (siehe das von RSK verlinkte Video zu Resolve) In Resolve: Einfach auf den Audiotrack gehen und per Rechtsklick "Convert to Linked Group" wählen. Dann kriegst Du zwei Mono-Tracks, die Du unabhängig voneinander pannen kannst. Super, kannte ich noch nicht! Vielen Dank.



Antwort von R S K:

Skeptiker hat geschrieben:
Einstellung: Maximale Qualität -> ProRes 40.3 Mbit/s - progressive Das ist natürlich unsinnig, denn man macht nichts anderes, als die Datei um das x-fache aufzublähen, ohne etwas zu gewinnen. Wäre höchstens die Frage ob die Wandlung in progressiv besser aussieht als einfach nur jede zweite Zeile rauszuschmeißen, was ich aber bezweifele.



Antwort von Skeptiker:

Muss noch weg und verabschiede mich vorläufig aus der Diskussion ..



Antwort von MK:

pillepalle hat geschrieben:
Pssst... nicht verraten das man Stereoaufnahmen (mit Ausnahme von matrizierten MS) gar nicht pannt. Die sind immer hart links und hart rechts. Aber machen kann man mit seiner Aufnahme prinzipiell natürlich alles.

VG Ach Du Scheiße, da hätten sich die Hersteller seit Dekaden die Panning-Regler an ihrer Unterhaltungselektronik sparen können, genial!



Antwort von pillepalle:

MK hat geschrieben:
Ach Du Scheiße, da hätten sich die Hersteller seit Dekaden die Panning-Regler an ihrer Unterhaltungselektronik sparen können, genial! Nicht ganz. Der ein oder andere möchte seine Monospuren ja vielleicht pannen ;)

VG



Antwort von MK:

Wäre natürlich gut wenn man gleich schreibt dass man zwei komplett unabhängige Kanäle aufgezeichnet hat die man abmischen möchte...



Antwort von MK:

pillepalle hat geschrieben:
Nicht ganz. Der ein oder andere möchte seine Monospuren ja vielleicht pannen ;) Vielleicht, hätte, könnte, wollte... nicht geschrieben.



Antwort von Asjaman:

MK hat geschrieben:
Vielleicht, hätte, könnte, wollte... nicht geschrieben. Schlimm. Also ich verbessere von "Stereo-Aufnahmen zur Bearbeitung" zu "2-Kanal-Aufnahmen zur Bearbeitung"
Ich gelobe, von Stereo nur noch als von einem Endformat zu sprechen, an dem selbstverständlich nicht rumgepannt wird ;-)



Antwort von Jott:

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! :-)






Antwort von TomStg:

Jott hat geschrieben:
Das ist kein Stereo. und auch keine Stereospur. Ich geb‘s auf, das ist wie gegen eine Wand reden! :-) Aber er kann bestimmt seinen Namen tanzen…



Antwort von Jott:

Skeptiker hat geschrieben:
Jott hat geschrieben:
Ganz normales Format mit zwei ganz normalen Tonspuren. Die aber auch 2 Sterospuren sein könnten (Audio 1 und Audio 2) ?

Hier ist es also z. B. ein Interview mit 2 Ansteckmikrofonen.
Wirrer geht‘s echt nicht mehr! :-)
Asjaman ist nicht der einzige, der massiv auf dem Schlauch steht. Ich versteh‘s einfach nicht.

Wenn jemand den Nerv hat, zu erklären, was eine Stereoaufnahme ist und was nicht - nur zu.



Antwort von cantsin:

Jott hat geschrieben:
Wenn jemand den Nerv hat, zu erklären, was eine Stereoaufnahme ist und was nicht - nur zu. Wikipedia hat den Job glücklicherweise bereits erledigt:

"Mit Stereofonie (von altgriechisch ??????? stereos, deutsch ‚hart, starr‘ und ???? f?n? ‚Laut‘, ‚Ton‘) werden Techniken bezeichnet, die mit Hilfe von zwei oder mehr Schallquellen einen räumlichen Schalleindruck beim natürlichen Hören erzeugen."

Zwei getrennte Mono-Kanäle sind genauso wenig Stereo wie sechs getrennte Mono-Kanäle Surround sind...



Antwort von cantsin:

Skeptiker hat geschrieben:
Bin auch zurück, mit einem Testergebnis:

Habe über Mittag mit QuickTime ein DV-Capturing per Firewire gemacht.
Der Ton ist PCM Stereo und wird als Audio1: '2 channels', 48 kHz/16 bit in MediaInfo angezeigt.
Ich schrieb zuvor etwas von einer zusätzlichen 32kHz/12bit Nachvertonungsspur für DV.
Das ist wohl keine Nachvertonungsspur, sondern es kann für die Aufnahme zwischen 2-Kanal 48/16 oder 4-Kanal 32/12 gewählt werden (die Gesamt-Datenrate bleibt gleich).

Beim Capture-Test ging es eher um Video (alle Angaben nur für Video, aus MediaInfoLib v19.09)

Mac OS 10.8.5
QuickTime 7.6.6 - Einstellung: Nativ -> DV 24.4 Mbit/s - interlaced
QuickTime 10.2 - Einstellung: Maximale Qualität -> DV 24.4 Mbit/s - interlaced

Mac OS 10.14.6
QuickTime 7.6.6 - Einstellung: Nativ -> DV 24.4 Mbit/s - interlaced
QuickTime 10.5 - Einstellung: Maximale Qualität -> ProRes 40.3 Mbit/s - progressive

Die Video-Abmessungen werden jeweils mit 720*576 (4:3) angegeben, ausser bei ProRes mit 702*576 (4:3).
Beim Öffnen mit QuickTime (7 oder 10) ist aber kein Grössen-Unterschied erkennbar. Hier muss man noch mal deutlich unterstreichen:

DV ist ein natives Datenformat bzw. der von der Kamera aufgezeichnete Codec. Wenn man DV als DV captured, hat man 1:1-Kopie der Aufnahmedaten, und zwar genauso, als wenn man Kamera-Videodaten von der SD-Karte auf den Rechner kopiert. (Nur dass hier kameraintern faktisch Tape-Streamer-Aufzeichnung verwendet wird wie bei Rechenzentren-Backups; obwohl äußerlich ähnlich, hat diese Technologie nichts mit herkömmlicher analoger Videokassettentechnik zu tun.)

Wenn man als ProRes captured bzw. transkodiert, verlässt man das native Dateiformat. Das ist ziemlich genau so, als wenn man ein mit der Digitalkamera aufgenommenes (8bit-) JPEG beim Kopieren auf den Rechner zu (16bit-) TIFF aufbläst.

Den Sinn davon kann sich jeder logisch ausrechnen.

Der Grund, warum beim DV-Capturen soviel Voodoo betrieben wird und einige Leute sogar über analoge Video-Capturekarten gehen, ist, dass DV (trotz seines Namens) wegen der Cassette als Analogvideotechnik missverstanden wird.



Antwort von dienstag_01:

cantsin hat geschrieben:
Skeptiker hat geschrieben:
Bin auch zurück, mit einem Testergebnis:

Habe über Mittag mit QuickTime ein DV-Capturing per Firewire gemacht.
Der Ton ist PCM Stereo und wird als Audio1: '2 channels', 48 kHz/16 bit in MediaInfo angezeigt.
Ich schrieb zuvor etwas von einer zusätzlichen 32kHz/12bit Nachvertonungsspur für DV.
Das ist wohl keine Nachvertonungsspur, sondern es kann für die Aufnahme zwischen 2-Kanal 48/16 oder 4-Kanal 32/12 gewählt werden (die Gesamt-Datenrate bleibt gleich).

Beim Capture-Test ging es eher um Video (alle Angaben nur für Video, aus MediaInfoLib v19.09)

Mac OS 10.8.5
QuickTime 7.6.6 - Einstellung: Nativ -> DV 24.4 Mbit/s - interlaced
QuickTime 10.2 - Einstellung: Maximale Qualität -> DV 24.4 Mbit/s - interlaced

Mac OS 10.14.6
QuickTime 7.6.6 - Einstellung: Nativ -> DV 24.4 Mbit/s - interlaced
QuickTime 10.5 - Einstellung: Maximale Qualität -> ProRes 40.3 Mbit/s - progressive

Die Video-Abmessungen werden jeweils mit 720*576 (4:3) angegeben, ausser bei ProRes mit 702*576 (4:3).
Beim Öffnen mit QuickTime (7 oder 10) ist aber kein Grössen-Unterschied erkennbar. Hier muss man noch mal deutlich unterstreichen:

DV ist ein natives Datenformat bzw. der von der Kamera aufgezeichnete Codec. Wenn man DV als DV captured, hat man 1:1-Kopie der Aufnahmedaten, und zwar genauso, als wenn man Kamera-Videodaten von der SD-Karte auf den Rechner kopiert. (Nur dass hier kameraintern faktisch Tape-Streamer-Aufzeichnung verwendet wird wie bei Rechenzentren-Backups; obwohl äußerlich ähnlich, hat diese Technologie nichts mit herkömmlicher analoger Videokassettentechnik zu tun.)

Wenn man als ProRes captured bzw. transkodiert, verlässt man das native Dateiformat. Das ist ziemlich genau so, als wenn man ein mit der Digitalkamera aufgenommenes (8bit-) JPEG beim Kopieren auf den Rechner zu (16bit-) TIFF aufbläst.

Den Sinn davon kann sich jeder logisch ausrechnen.

Der Grund, warum beim DV-Capturen soviel Voodoo betrieben wird und einige Leute sogar über analoge Video-Capturekarten gehen, ist, dass DV (trotz seines Namens) wegen der Cassette als Analogvideotechnik missverstanden wird. Hm, naja, natives Dateiformat. Das gibt es natürlich nicht. Es gibt DV Codecs von verschiedenen Anbietern und je nach NLE wird in verschiedene Dateiformate gecaptured. DV bleibt es natürlich.
Den Rest kann man aber unterschreiben, vielleicht noch hinzufügen, dass beim Capturen in DV/HDV eigentlich nicht diese Art Fehler wie bei Skeptiker oben passieren können, dass aus interlaced plötzlich progressiv wird ;)



Antwort von cantsin:

dienstag_01 hat geschrieben:
Hm, naja, natives Dateiformat. Das gibt es natürlich nicht. Definitionssache. Es gibt ".dv" als Dateiformat (spezifiziert/standardisiert als Teil von "DV-DIF"), das den rohen Datenstrom ohne ein umgebendes Containerformat (wie .mov oder .avi) enthält, und das auch von allen gängigen NLEs und Videoplayern unterstützt wird. Wenn man von der Cassette in eine .dv-Datei capturt, hat man identische Daten auf Band und Festplatte.

https://www.loc.gov/preservation/digita ... 0173.shtml



Antwort von dienstag_01:

cantsin hat geschrieben:
dienstag_01 hat geschrieben:
Hm, naja, natives Dateiformat. Das gibt es natürlich nicht. Definitionssache. Es gibt ".dv" als Dateiformat (spezifiziert/standardisiert als Teil von "DV-DIF"), das den rohen Datenstrom ohne ein umgebendes Containerformat (wie .mov oder .avi) enthält, und das auch von allen gängigen NLEs und Videoplayern unterstützt wird. Wenn man von der Cassette in eine .dv-Datei capturt, hat man identische Daten auf Band und Festplatte.

https://www.loc.gov/preservation/digita ... 0173.shtml Ein Dateiformat verlangt eine Datei. Auf dem Band werden keine Dateien gespeichert.
Das dv von allen NLEs unterstütz wurde, halte ich für ein Gerücht.
Wahrscheinlich hätte es dann gar keine Container gegeben ;)

Der entscheidende Punkt ist hier wie immer der Codec, der muss DV oder HDV sein. Nativer geht es dann nicht.



Antwort von cantsin:

dienstag_01 hat geschrieben:
Ein Dateiformat verlangt eine Datei. Auf dem Band werden keine Dateien gespeichert. Hatte ich auch nicht geschrieben, lies noch mal richtig.



Antwort von R S K:

dienstag_01 hat geschrieben:
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.






Antwort von dienstag_01:

cantsin hat geschrieben:
dienstag_01 hat geschrieben:
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.



Antwort von Asjaman:

Jott hat geschrieben:
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.



Antwort von 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! ;-)



Antwort von cantsin:

Skeptiker hat geschrieben:
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...



Antwort von Skeptiker:

cantsin hat geschrieben:
Skeptiker hat geschrieben:
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 .. .. ;-)



Antwort von dienstag_01:

Skeptiker hat geschrieben:
cantsin hat geschrieben:


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.



Antwort von cantsin:

dienstag_01 hat geschrieben:
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



Antwort von MK:

cantsin hat geschrieben:
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.



Antwort von Jott:

dienstag_01 hat geschrieben:
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?






Antwort von dienstag_01:

Jott hat geschrieben:
dienstag_01 hat geschrieben:
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.



Antwort von 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.



Antwort von dienstag_01:

Jott hat geschrieben:
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.



Antwort von 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.



Antwort von dienstag_01:

Jott hat geschrieben:
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.



Antwort von 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 …



Antwort von dienstag_01:

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



Antwort von MK:

Jott hat geschrieben:
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.



Antwort von Jott:

Asjaman hat geschrieben:
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?



Antwort von Asjaman:

Jott hat geschrieben:
Asjaman hat geschrieben:
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.



Antwort von 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.



Antwort von MK:

Jott hat geschrieben:
"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.



Antwort von Jott:

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

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



Antwort von MK:

Jott hat geschrieben:
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.



Antwort von MK:

Jott hat geschrieben:
Ich persönlich habe eine Broadcaster-Allergie, mit denen kann ich nicht. Ich brauche das Geld... :-(



Antwort von Asjaman:

Jott hat geschrieben:
"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



Antwort von Jott:

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

Oder sieht das jemand ernsthaft anders?



Antwort von Asjaman:

Jott hat geschrieben:
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.



Antwort von 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.



Antwort von Asjaman:

Jott hat geschrieben:
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? ;-)



Antwort von Jott:

Ja, dein weiteres Schicksal! :-)



Antwort von Asjaman:

Jott hat geschrieben:
Ja, dein weiteres Schicksal! :-) Ein schönes Schlusswort.