MCEBuddy benutzerdefinierte Schnitte und Untertitel

Ich versuche, MCEBuddy Custom Cuts zu verwenden, und obwohl die EDL zu funktionieren scheint und die Datei wie erwartet erzeugt wird, scheint es ein Problem beim Erhalten der Untertitel zu geben.

Ein Blick in die Log-Datei zeigt, dass zwar die Untertitel in der Quelle erkannt werden, sie aber nicht in die temporäre .ts-Kopie im working0-Ordner übernommen werden:

2019-09-25T12:02:50 MCEBuddy.AppWrapper.FFmpeg --> Launching process C:\Program Files\MCEBuddy2x\ffmpeg\ffmpeg.exe
2019-09-25T12:02:50 MCEBuddy.AppWrapper.FFmpeg --> Process arguments  -hide_banner -probesize 100M -analyzeduration 300M -y -i "E:\Inbound\NFL Football\NFL Football - S2019E2037 - Los Angeles Chargers at Detroit Lions.m4v"  -ss 0 -vcodec copy -acodec copy -map 0:a -map 0:0 -f mpegts "C:\Program Files\MCEBuddy2x\working0\NFL Football - S2019E2037 - Los Angeles Chargers at Detroit Lions.ts"
2019-09-25T12:02:50 MCEBuddy.AppWrapper.FFmpeg --> UI Session Admin Process : True
2019-09-25T12:02:50 MCEBuddy.AppWrapper.FFmpeg --> Starting process as a UISession process with Admin privileges. This requires atleast 1 user to be logged into the system (remote desktop or locally)
2019-09-25T12:02:50 MCEBuddy.AppWrapper.FFmpeg --> Setting process priority to Normal
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg --> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'E:\Inbound\NFL Football\NFL Football - S2019E2037 - Los Angeles Chargers at Detroit Lions.m4v':
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->   Metadata:
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     major_brand     : mp42
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     minor_version   : 512
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     compatible_brands: isomiso2mp41
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     creation_time   : 2019-09-15T21:33:58.000000Z
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     encoder         : MCEBuddy
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     date            : 1900-01-01T12:00:00Z
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     RecordingTimestamp: 1900-01-01T12:00:00
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     SeriesPremiere  : 1900-01-01T12:00:00
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     CopyProtected   : False
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     title           : Los Angeles Chargers at Detroit Lions
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     show            : NFL Football
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     season_number   : 227
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     episode_sort    : 245
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     media_type      : 10
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->   Duration: 02:52:45.53, start: 0.000000, bitrate: 12369 kb/s
--> Video duration=10365.53
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     Stream #0:0(und): Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 12199 kb/s, 29.67 fps, 29.97 tbr, 90k tbn, 29.97 tbc (default)
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     Metadata:
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->       creation_time   : 2019-09-15T21:33:58.000000Z
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->       handler_name    : VideoHandler
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s (default)
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     Metadata:
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->       creation_time   : 2019-09-15T21:33:58.000000Z
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->       handler_name    : SoundHandler
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     Stream #0:2(spa): Subtitle: mov_text (tx3g / 0x67337874), 1920x162, 0 kb/s (default)
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     Metadata:
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->       creation_time   : 2019-09-15T21:33:58.000000Z
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->       handler_name    : SubtitleHandler
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg --> Output #0, mpegts, to 'C:\Program Files\MCEBuddy2x\working0\NFL Football - S2019E2037 - Los Angeles Chargers at Detroit Lions.ts':
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->   Metadata:
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     major_brand     : mp42
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     minor_version   : 512
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     compatible_brands: isomiso2mp41
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     media_type      : 10
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     episode_sort    : 245
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     date            : 1900-01-01T12:00:00Z
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     RecordingTimestamp: 1900-01-01T12:00:00
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     SeriesPremiere  : 1900-01-01T12:00:00
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     CopyProtected   : False
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     title           : Los Angeles Chargers at Detroit Lions
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     show            : NFL Football
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     season_number   : 227
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     encoder         : Lavf58.24.100
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s (default)
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     Metadata:
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->       creation_time   : 2019-09-15T21:33:58.000000Z
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->       handler_name    : SoundHandler
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     Stream #0:1(und): Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 12199 kb/s, 29.67 fps, 29.97 tbr, 90k tbn, 90k tbc (default)
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->     Metadata:
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->       creation_time   : 2019-09-15T21:33:58.000000Z
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->       handler_name    : VideoHandler
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg --> Stream mapping:
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->   Stream #0:1 -> #0:0 (copy)
2019-09-25T12:02:51 MCEBuddy.AppWrapper.FFmpeg -->   Stream #0:0 -> #0:1 (copy)

Ich hänge auch die vollständige Log-Datei an diesen Beitrag. Gibt es etwas Offensichtliches, das ich übersehe? Vielen Dank im Voraus für jegliche Hilfe!
NFL Football - S2019E2037 - Los Angeles Chargers at Detroit Lions.m4v-Football-2019-09-25T12-02-07.0358516-04-00.log (3,3 MB)

Ich grabe weiter in diesem Thema. Ich habe zufällig ein Skript, das ich wegen eines anderen kürzlichen Problems, auf das ich gestoßen bin, verwende, um .srt-Dateien zu extrahieren. Mit diesem Skript kann ich die .srt-Datei extrahieren, die von MCEBuddy erkannt wird, wenn sie zur Warteschlange hinzugefügt wird. Leider scheint es, dass die .srt-Datei dann kopiert und nicht eingebettet wird.

Ich muss die .srt dann zu Plex hochladen, da sie aus irgendeinem Grund nicht sofort erkannt und aktualisiert wird.

Kaum ideal und viele Schritte. Ich würde mich über weitere Gedanken/Vorschläge zur Verbesserung dieses Workflows freuen. :+1:

Sie haben die Option Exakte Untertitel und Untertitel in der Konvertierungsaufgabe nicht aktiviert, daher werden sie nie extrahiert (und folglich auch nicht eingebettet, obwohl Sie diese Option aktiviert haben)

Closed Captions →

Ahhh leider hat das das Problem nicht gelöst. Wenn ich bei der Konvertierungsaufgabe Geschlossene Untertitel und Untertitel extrahieren auswähle, wird eine .srt-Datei extrahiert und in denselben Ordner wie die ausgegebene .mp4-Datei gelegt, wenn ich eine .ts-Datei eingebe. Die resultierende .mp4-Datei hat ebenfalls die Untertitel eingebettet.

(Ich sollte anmerken, dass Untertitel auch ohne die Verwendung von Geschlossene Untertitel und Untertitel extrahieren in die .mp4-Datei eingebettet werden.)

Soweit, so gut.

Wenn ich jedoch anschließend Custom Cuts verwende, um zusätzliche Bearbeitungen in eine .edl-Datei zu erstellen und danach Mit MCEBuddy verarbeiten, wird die Datei zur Warteschlange hinzugefügt, mit derselben Konvertierungsaufgabe verarbeitet, aber die extrahierte .srt-Datei wird niemals eingebettet.

Vielleicht mache ich etwas furchtbar falsch?

Logs bitte

Boh! Entschuldigung dafür.

Hier sind die Logs von der ersten (erfolgreichen, wie erwartet funktionierenden) Konvertierung von .ts.m4v:

NFL Football - S2019E2037 - Los Angeles Chargers at Detroit Lions.ts-Football-2019-09-27T07-52-33.2881663-04-00.log (7,3 MB)

Dies erzeugt eine .m4v-Datei, die genau wie erwartet ist und die eingebetteten Untertitel enthält. Entsprechend gibt es nun, nachdem ich in der Konvertierungsaufgabe Untertitel und Untertitel extrahieren aktiviert habe, auch eine entsprechende .srt-Datei im Ausgabeverzeichnis.

Dann öffne ich diese neu erstellte .m4v-Datei in Custom Cuts, erstelle Schnittpunkte und speichere dann die .edl.

Jetzt habe ich in meinem Ausgabeverzeichnis:

  • .m4v-Datei
  • .srt-Datei
  • .edl-Datei

Denken Sie daran, dass die .m4v-Datei wie erwartet eingebettete Untertitel enthält.

Ich klicke dann auf Mit MCEBuddy verarbeiten in Custom Cuts, was folgende Ausgabe erzeugt:

NFL Football - S2019E2037 - Los Angeles Chargers at Detroit Lions.m4v-Football-2019-09-27T10-47-49.2347885-04-00.log (2,5 MB)

Jetzt habe ich die oben aufgeführten 3 Dateien und eine neue kleinere .srt-Datei, die aus der obigen erzeugt wurde, aber mit einer 0 angehängt an den Hauptnamen (NFL Football - S2019E2037 - Los Angeles Chargers at Detroit Lions0.srt).

Zusätzlich enthält die .m4v-Datei keine eingebetteten Untertitel mehr, wie sie es bei der .ts.m4v-Konvertierung noch hatte.

Bitte lassen Sie mich wissen, ob Sie zusätzliche Informationen benötigen, um dieses Problem weiter zu diagnostizieren.

Mit Ihrer SRT-Datei oder der Videodatei stimmt etwas nicht, MCEBuddy kann sie nicht hinzufügen:

2019-09-27T11:18:58 MCEBuddy.AppWrapper.MP4Box → Launching process C:\Program Files\MCEBuddy2x\mp4Box\mp4box.exe
2019-09-27T11:18:58 MCEBuddy.AppWrapper.MP4Box → Process arguments -add “C:\Program Files\MCEBuddy2x\working0\NFL Football - S2019E2037 - Los Angeles Chargers at Detroit Lions.srt”:hdlr=sbtl:lang=eng “C:\Program Files\MCEBuddy2x\working0\NFL Football - S2019E2037 - Los Angeles Chargers at Detroit Lions.m4v”
2019-09-27T11:18:58 MCEBuddy.AppWrapper.MP4Box → UI Session Admin Process : False
2019-09-27T11:18:58 MCEBuddy.AppWrapper.MP4Box → Setting process priority to Normal
→ Process exited with code -1073741515

Wenn Sie die ursprünglichen SRT-, EDL- und M4V-Dateien hochladen können, können wir uns das ansehen.

Großartig! Vielen Dank für Ihre Unterstützung. Ich habe die Dateien hier zur Überprüfung bereitgestellt:

Bitte lassen Sie mich wissen, ob Sie weitere Informationen oder Artikel benötigen, um dieses Problem weiter zu beheben/zu debuggen.

Ich bin hier etwas verwirrt. Laut der Log-Datei, die Sie oben angehängt haben, wird gezeigt, dass eine TS-Datei in M4V konvertiert wurde und dass dabei keine Untertitelspuren in die endgültige M4V-Datei eingebettet wurden, wie ich aus den obigen Logs hervorgehoben habe.

Die hochgeladene M4V-Datei enthält jedoch eine Untertitelspur, und ich kann sie abspielen. Was für eine Datei haben Sie also hochgeladen?

Entschuldigung für die Verzögerung, @RBoy. Ich war außer Haus und bin erst gestern zurückgekommen; heute Vormittag konnte ich weitere Informationen für Sie hochladen.

Zur Wiederholung: In dem von uns besprochenen Szenario finden zwei Konvertierungen statt:

  1. (als First bezeichnet) .ts.m4v. MCEBuddy führt diese Konvertierung entweder durch, wenn Plex eine Nachbearbeitung ausführt, oder wenn eine .ts-Datei direkt in die MCEBuddy-Warteschlange eingefügt wird. Jedes Mal funktioniert diese Konvertierung einwandfrei: Die Datei wird umgewandelt und die Untertitel im resultierenden .m4v eingebettet. Dabei war Extract closed captions and subtitles nicht nötig. Wenn ich von „eingebetteten“ Untertiteln spreche, meine ich, dass sie in der .m4v-Datei enthalten sind und ich sie sehen kann, wenn ich diese .m4v-Datei in ein neues Verzeichnis kopiere und sie mit Handbrake untersuche:

  2. (als Second bezeichnet) .m4v.m4v. Bei dieser Konvertierung nehme ich das Ergebnis der First-Konvertierung (das bereits eingebettete Untertitel enthält), erstelle mit Custom Cuts die .edl-Datei und verwende anschließend Process with MCEBuddy, um sie in die MCEBuddy-Warteschlange zu übergeben. Obwohl das Eingabefile von First eingebettete Untertitel enthält, schaffen diese es nicht in das Ausgabefile der Second-Konvertierung – weder mit noch ohne Extract closed captions and subtitles.

Wie bereits erwähnt, habe ich ein zusätzliches Beispiel für dieses Szenario von Grund auf erstellt und in den oben genannten freigegebenen Ordner hochgeladen (zusätzlich zum Archiv des vorherigen Beispiels). Im freigegebenen Ordner sollten nun insgesamt drei Ordner vorhanden sein:

  1. .Archive enthält die bisherigen Dateien. Sie können diesen Ordner ignorieren; er dient nur der Historie.
  2. First enthält die Eingabe (.ts), die Ausgaben (.m4v) sowie die .log-Datei der oben beschriebenen First-Konvertierung. Das ist die .ts.m4v-Konvertierung, die wie erwartet funktioniert und zu eingebetteten Untertiteln führt. Die Ausgaben dieser Konvertierung wurden in einen neuen Ordner kopiert und als Eingaben für die nächste (Second) Konvertierung verwendet.
  3. Second enthält die Ausgaben der oben beschriebenen Second-Konvertierung. Das ist die .m4v.m4v-Konvertierung inklusive der .log-Datei, die durch Custom Cuts erzeugt wurde. Dieser Ordner enthält die resultierende .m4v-Datei, bei der die Untertitel nicht eingebettet werden.

Insgesamt sollten Sie sehen, dass First\NFL Football - S2019E2069 - Kansas City Chiefs at Detroit Lions.m4v eingebettete Untertikel enthält, wohingegen Second\NFL Football - S2019E2069 - Kansas City Chiefs at Detroit Lions.m4v keine enthält.

Bitte teilen Sie mir mit, falls Sie weitere Informationen benötigen.

Ich wollte mich bezüglich dieses Problems melden. Bitte lassen Sie mich wissen, ob ich weitere Informationen zur Diagnose und/oder Lösung beisteuern kann. Es wäre auch hilfreich zu erfahren, ob die von mir bereitgestellten Informationen nützlich sind und/oder ob Sie das Problem mit den vorliegenden Daten nachvollziehen konnten. Vielen Dank!

Ich sehe in den Protokollen, dass das Hinzufügen der Untertitel zu Ihrer Datei fehlgeschlagen ist:

→ Process exited with code -1073741515

Als ich es hier mit Ihren Einstellungen und der ursprünglichen M4V-Datei versuchte, funktionierte es einwandfrei:

2019-10-16T13:53:27 MCEBuddy.AppWrapper.MP4Box → ISO File Writing: |====================| (100/100)
2019-10-16T13:56:29 MCEBuddy.AppWrapper.MP4Box →
→ Process exited with code 0
2019-10-16T13:56:38 MCEBuddy.Engine.ConversionJob → Finished adding subtitles and chapters to file, file size [KB] 10,283,663.00

Es gibt ein Problem mit Ihrem Setup, das MP4Box daran hindert, die Untertitel hinzuzufügen. Ich sehe, dass Sie genug Speicherplatz haben, also weiß ich nicht wirklich weiter. Alles, was ich sagen kann, ist: Versuchen Sie es mit einem anderen Laufwerk für Ihren temporären Ordner oder mit einem anderen Computer.

OK cool, danke für deine Hilfe und Antwort, @RBoy… Ich versuche immer noch, die verschiedenen Einstellungen hier zu verstehen, also bitte hab noch etwas Geduld mit mir. In der First-Konvertierungsaufgabe sehe ich denselben Fehlercode von MP4Box, aber dabei werden die Untertitel wie erwartet eingebettet.

Ich war auch der Meinung, dass Handbrake zum Einbetten von Untertiteln verwendet wird, bin mir also nicht zu 100 % sicher, dass MP4Box der Übeltäter ist (oder verstehe es zumindest noch nicht). Es gibt hier auf jeden Fall viele bewegliche Teile. :sweat_smile:

Handbrake wird verwendet, um Untertitel zu brennen (nicht einzubetten).

MP4Box ist der letzte Schritt im Prozess, um die Untertitel einzubetten. Die Protokolle zeigen, dass nach Abschluss keine Untertitel in der Datei vorhanden sind, dort liegt also das Problem. Ich bin mir nicht sicher, warum – wie gesagt, funktioniert Ihre Datei und Ihr Profil hier einwandfrei. Sie können eine andere Festplatte/einen anderen Computer ausprobieren und schauen, ob das hilft.

Ich habe mir deine Logs noch einmal angesehen: Im ersten Fall waren die Untertitel Teil des TS-Streams und als Closed Captions gespeichert. Du hast ein benutzerdefiniertes Profil verwendet, das HandBrake angewiesen hat, diese eingebetteten Closed Captions zu verwenden und zu erhalten – daher hat es funktioniert:

2019-09-27T08:19:21 MCEBuddy.AppWrapper.Handbrake → + subtitle tracks:
2019-09-27T08:19:21 MCEBuddy.AppWrapper.Handbrake → + 1, español, Closed Caption [CC608]

Du kannst versuchen, die Option Skip remuxing in den Experteneinstellungen zu aktivieren. Dadurch arbeitet HandBrake direkt mit der originalen M4V-Datei statt mit der remuxten TS-Datei; möglicherweise erkennt es so die eingebetteten Untertitel und kann sie verwenden.

Ah, also um sicherzugehen, dass ich es richtig verstehe: Meinst du, die Logs sagen, dass die Untertitel nicht eingebettet sind, aber in der resultierenden Datei sind sie tatsächlich vorhanden? Ich kann First\\NFL Football - S2019E2069 - Kansas City Chiefs at Detroit Lions.m4v sowohl in Handbrake als auch in VLC öffnen und sehe dort die Untertitel als Ergebnis der ersten Konvertierungsaufgabe eingebettet. Auch hier enthält die Log-Datei für diese Aufgabe denselben Fehlercode wie bei Second, den du erwähnt hast.

Leider habe ich keine andere Maschine/Umgebung zur Verfügung, um das auszuprobieren, also muss ich schauen, ob ich es mit der aktuellen Konfiguration zum Laufen bekomme – falls überhaupt möglich.

Bei der ersten Konvertierung handelt es sich bei Ihrer Originaldatei um eine TS-Datei, die geschlossene Untertitel enthält. MCEBuddy extrahiert diese geschlossenen Untertitel als SRT-Datei, kann sie jedoch nicht einbetten, da MP4Box fehlschlägt.

Sie haben jedoch ein benutzerdefiniertes Profil, und in diesem Profil weisen Sie HandBrake an, während der Konvertierung nach geschlossenen Untertiteln zu suchen. Es findet diese gemuxten geschlossenen Untertitel im TS-Stream und konvertiert sie automatisch in eine eingebettete SRT-Datei.

Bei der zweiten Konvertierung starten Sie mit einer M4V-Datei mit der eingebetteten SRT-Datei. MCEBuddy extrahiert die SRT-Datei und remuxt die M4V-Datei in das TS-Format zur Verarbeitung (das keine Untertitel oder geschlossenen Untertitel enthält). Daher erkennt HandBrake nichts, und wenn MCEBuddy schließlich versucht, diese Untertitel wieder in den Container einzufügen, schlägt es bei Ihrer Konfiguration fehl.

Sie haben drei Möglichkeiten:

  1. Versuchen Sie einen anderen Computer, auf dem MP4Box nicht fehlschlägt (es funktioniert hier unter Windows 10, 64-Bit).
  2. Aktivieren Sie die Option Remuxen überspringen für Ihre zweite Konvertierungsaufgabe (auf diese Weise wird MCEBuddy die M4V-Datei nicht in TS remuxen, und wenn HandBrake die ursprüngliche M4V-Datei erhält, kann es möglicherweise die eingebettete SRT-Datei erkennen und beibehalten).
  3. Ändern Sie Ihr Profil für die zweite Konvertierung, um HandBrake anzuweisen, die von MCEBuddy extrahierte SRT-Datei zusammen mit der remuxten TS-Datei im temporären Ordner zu verwenden und in Ihre konvertierte M4V-Datei einzubetten. Versuchen Sie, --srt-file <source_without_ext>.srt zur handbrake-video-Zeile in Ihrem Profil hinzuzufügen. Siehe Einfügen spezieller Befehle für Details darüber, wie <source_without_ext> funktioniert.

Ok! Das ergibt für mich jetzt Sinn, @RBoy. Vielen Dank, dass du dir die Zeit genommen und die Geduld aufgebracht hast, mir das zu erklären. Ich glaube, ich habe jetzt genug, um die nächsten Schritte zu gehen. Ich werde versuchen, den Befehl --srt-file zum Laufen zu bekommen, und wenn nicht, werde ich versuchen herauszufinden, warum die Maschine den MP4Box-Fehler ausgibt.

Nochmals vielen Dank an dich und alle dort für eure großartige Arbeit mit diesem Produkt – und, noch wichtiger – für eure Unterstützung! :+1:

Gern geschehen, nimm dir eine Minute, um uns beim Weitersagen zu helfen

So lustig, was sich auf dem Weg beim Ausprobieren hier ereignet hat. :sweat_smile: Ich habe diesen Thread nochmal durchgesehen und es scheint, dass ich deinen früheren Beitrag übersehen habe – und auch diesen anschließenden Vorschlag.

Ich habe versucht, eine neue Konvertierungsaufgabe mit SkipRemux=True zu erstellen. Wenn ich sie auf die .m4v-Datei aus der ersten Aufgabe anwende, werden die Untertitel korrekt exportiert – Juchhu! Allerdings scheint sie die .edl-Datei, die von Custom Cuts erstellt wurde, nicht zu berücksichtigen – Mist.

Daher wollte ich fragen, ob hier etwas Offensichtliches zu beachten ist. Was mir an diesem Ansatz gefällt, ist, dass ich die Option Extract closed captions and subtitles deaktivieren kann und mir so eine zusätzliche Datei pro Konvertierung spare.