|
Anzeige
|
mp3 Abspieler der zum nächsten Kapitel im selben File springen kann?
Gast
#6515614
Hi, kennt jemand 'n mp3 Abspieler(für Linux) der auf Knopfdruck zum nächsten Kapitel im selben File springen kann? mediainfo meint zu diesen Files z.B.: Menu 00:00:00.000 : Intro 00:00:10.856 : Thema: blahbahhh
Gast
#6516261
Schau mal ob der mplayer das kann. Der unterstützt normal diverse solcher Funktionen.
Gast
#6516276
Das ist LEIDER unmöglich das mp3 keine Kapitel-Infos hat. Weshalb vermutlich viele Anbietern von langen Audiofiles dazu übergegangen sind ihre Kapitel in Files zu unterteilen. Ich kenne nicht einmal einen Player der nach Playliste Zeitkoordinaten anspringen kann.
Gast
#6516299
@Schlaumeier Das gelesen? Wenn ich von etwas keine Ahnung habe bin ich lieber Still. Tim B. schrieb: > mediainfo meint zu diesen Files z.B.: > > Menu > 00:00:00.000 : Intro > 00:00:10.856 : Thema: blahbahhh
Gast
#6516306
Ich habe Ahnung. In mp3 sind keine Kapitel möglich. PUNKT. https://www.audiobeitraege.de/kapitelmarken-mit-audacity-erstellen/ Zitat : Wenn Sie jetzt Ihre Datei exportieren, werden die Marken leider nicht übernommen. Doch Sie können im Menü über Datei > Textmarken exportieren eine Textdatei erstellen, eine DATEINAME.txt-Datei, die die Marken enthält. Deine Mediainfo sucht ergo das Textfile. Da man aber in mp3 springen kann, macht die Software genau DAS. Sie liest das Textfile und Springt auf die Zeiteinheit. Leider kenne ich nicht einmal unter Windows / Android ein Player der diese Möglichkeit nutzt. Für Android wäre es sogar schön wenn es den gibt. Da benutzte ich aktuell musik-folder-play. Der schafft es wenigstens nur 1 Verzeichnis abzuarbeiten. Schlaumaier schrieb: > Ich habe Ahnung. Ganz offensichtlich nicht. > In mp3 sind keine Kapitel möglich. PUNKT. Das ist Blödsinn. Kapitel-Infos können als Teil des ID3-Tag abgelegt werden. Siehe https://id3.org/id3v2-chapters-1.0 Angeblich gibt es für Linux einen Audiobook-Player namens "Cozy", der das können soll, aber das hab ich selbst noch nicht probiert.
Gast
#6516346
Schlaumaier schrieb: > Das ist LEIDER unmöglich das mp3 keine Kapitel-Infos hat. Das stimmt zumindest ein bisschen. MP3 selber hat tatsächlich keinerlei solche Infos zu bieten. Allerdings kommt MP3 gern in Kombination mit ID3V2 als eingebettetem Metadaten-Container. Und ID3V2 kann sowas natürlich sehr wohl abbilden. Die allermeisten Player können mit ID3V2 auch grundsätzlich umgehen, aber i.d.R. nur wenige von dessen Features benutzen. Typisch ist, dass die mit den wesentlichen sog. TextInformationFrames (z.B. Titel, Album, Künstler, Spieldauer usw.) umgehen können, oft auch mit den COMM- (=Kommentar) Frames. Aber darüber hinaus wird es doch sehr schnell sehr eng. Man müsste also als erstes mal in Erfahrung bringen, welche ID3-Frames hier genau verwendet werden. Es kommen nämlich durchaus mehrere in Frage. Dann wüßte man, nach welcher Unterstützung genau man für einen passenden Player suchen muss. @TO: poste doch mal die ersten 10..20 kByte so einer Datei, dann kann man weiter sehen...
Gast
#6516351
Rolf M. schrieb: > Schlaumaier schrieb: >> Ich habe Ahnung. > > Ganz offensichtlich nicht. > >> In mp3 sind keine Kapitel möglich. PUNKT. > > Das ist Blödsinn. Kapitel-Infos können als Teil des ID3-Tag abgelegt > werden. Siehe https://id3.org/id3v2-chapters-1.0 Rein formal gesehen gehört id3v2 nicht zur mp3-Spec. Insofern hätte Schlaumaier Recht... Planloser schrieb: > Rein formal gesehen gehört id3v2 nicht zur mp3-Spec. Insofern hätte > Schlaumaier Recht... Auch wenn sie nicht Teil der mp3-Spezifikation selbst sind, sind sie dort dennoch möglich. Und es gibt auch eine konkrete Spezfikation dafür, das heißt, diese Möglichkeit ist nicht nur rein theoretisch. Seine Aussage war aber: Planloser schrieb: > In mp3 sind keine Kapitel möglich. PUNKT.
Gast
#6516443
OK. über den IDv2 Track mag es gehen. Aber dann muss der Player unterscheiden zwischen JPG (Ich habe viele Mp3 mit ein Bildchen drin) + Track-Info (Interpret, Titel, Album etc) + Kapitel-Liste. Und da es wie bereits gesagt keine offiziellen Spezifikationen gibt, gibt es ergo auch kein Signatur-Schlüssel (Bit/Byte-Zeichenfolge) die das auseinander hält. Was vermutlich der Grund ist, wieso es kein mir und den TO bekannten Player gibt der das unterstützt. Die Trennung zwischen Trackinfo und Bild ist übrigens "APIC" als Schlüsselcode.
Gast
#6516448
Nachtrag: https://de.wikipedia.org/wiki/ID3-Tag Hier ist klar zu sehen was rein darf und was die rein-panschen mit der Kapitelliste. Und da es da wie gesagt kein Schlüsselcode gibt macht das auch kein Seriöser Player. Schlaumaier schrieb: > Was vermutlich der Grund ist, wieso es kein mir und den TO bekannten > Player gibt der das unterstützt. BSPlayer kann das, nützt dem TO aber glaube ich nichts(?). VLC soll das angeblich auch können (nicht bei meinem Test). Da das aber nich offiziell ist, soll da unterschiedlichen Süppchen gekocht werden. -> Ausprobieren. :/
Gast
#6516491
Schlaumaier schrieb: > OK. über den IDv2 Track mag es gehen. Aber dann muss der Player > unterscheiden zwischen JPG (Ich habe viele Mp3 mit ein Bildchen drin) + > Track-Info (Interpret, Titel, Album etc) + Kapitel-Liste. Das kann er natürlich. Genau dafür gibt es die vielen verschiedenen ID3-Frames. > Und da es wie bereits gesagt keine offiziellen Spezifikationen gibt, > gibt es ergo auch kein Signatur-Schlüssel (Bit/Byte-Zeichenfolge) die > das auseinander hält. Lach'... Es gibt auch keine offizielle Spezifikation all der Quasi-Standards, die die Funktionsweise des "Internet" beschreiben, nur RFCs. Das Internet funktioniert aber trotzdem ganz ordentlich... Merke: eine offizielle Standardisierung ist einerseits nicht hinreichend, andererseits aber auch nicht notwendig für die Funktion einer Sache... > Die Trennung zwischen Trackinfo und Bild ist übrigens "APIC" als > Schlüsselcode. "APIC" ist die ASCII-Entsprechung des Headers, der im Kontext des durch einen ID3V2-Header beschriebenen Datenbereichs darauf hinweist, dass da jetzt ein APIC-Frame liegt. Das sagt erstmal nur aus, dass dieser Frame mit einiger Wahrscheinlichkeit ein Bild enthält. Der Frameheader beschreibt allein aber weder Format noch Codierung dieses Bildes, nur wo dessen Daten zu finden sind und wie groß sie sind. Dazu kommt noch ein Haufen Bullshit-Stuff, in dem sich z.T. mies aufgelegte Entwickler verewigt haben. Diese Sache zieht sich allerdings generell durch ID3V3... Schlaumaier schrieb: > Nachtrag: > https://de.wikipedia.org/wiki/ID3-Tag > > Hier ist klar zu sehen was rein darf und was die rein-panschen mit der > Kapitelliste. Da findet man weder eine komplette Liste davon, was rein darf (lediglich "Gängige ID3v2-Tags (Auswahl)"), noch etwas über Kapitel. Und die Kapitelliste ist genauso (in)offiziell wie ID3v2 selbst - im Gegensatz zu einigem Zeug, das iTunes da wohl dazubastelt, wie man auf https://id3.org/Developer%20Information sehen kann. > Und da es da wie gesagt kein Schlüsselcode gibt macht das auch kein > Seriöser Player. Ich weiß nicht, was du damit meinst. Jeder ID3-Frame hat eine 32-bittige id, die kennzeichnet, was drin ist. Diese ids können als Strings aus 4 ASCII-Zeichen dargestellt werden. Bei Bildern ist das "APIC", wie du richtig festgestellt hast, wobei das nicht, wie du sagt die "Trennung zwischen Trackinfo und Bild" ist, sondern einfach Teil eines Headers, der sagt, dass das ein Frame ist, der ein Bild enthält. Wenn da stattdessen "TALB" stehten würde, wäre es ein Frame, der den Album-Namen enthält. Alle Informationen in einem ID3-Tag sind als solche Frames definiert. Und bei Kapiteln ist das "CHAP" und beim Inhaltsverzeichnis "CTOC".
Gast
#6516554
Und wieso muss der TO hier suchen wenn es doch mp3-Player wie Sand am Meer gibt. Weil diesen Kapitelzeug keiner will-// macht // unsinnig findet // oder was auch immer. Ich würde da doch auch gerne den Grund erfahren. Schlaumaier schrieb: > Und wieso muss der TO hier suchen wenn es doch mp3-Player wie Sand am > Meer gibt. Wer hat behauptet, dass es die wie Sand am Meer gäbe? > Weil diesen Kapitelzeug keiner will-// macht // unsinnig findet // oder > was auch immer. Henne/Ei-Problem? Keiner erzeugt Files, die Kapitel-Infos enthalten, weil es keine Player gibt, die das können, und die Player implementieren es nicht, weil das ja keiner nutzt. Aber es gibt sie wohl anscheinend doch. Siehe https://auphonic.com/blog/2013/07/03/chapter-marks-and-enhanced-podcasts/ Dort findet man auch einen Link auf https://docs.google.com/spreadsheet/ccc?key=0AjVIXWN8HnOedEpwZllJV0RRMmtqbUFrSmJ5ZFVSekE#gid=0 , wo man nach der Spalte "MP3 Chapter Mark Support" suchen kann.
Gast
#6516616
Rolf M. schrieb: > Henne/Ei-Problem? Oder es die klassische babylonische Verwirrung?: Es gibt mindestens 4 verschiedene Verfahren die Kapitel in einem .mp3 File abwärtskompatibel zu verstecken. Auch mediainfo --Full (Version 20.09) kann nicht alle anzeigen :-(
Gast
#6516633
Schlaumaier schrieb: > Ich würde da doch auch gerne den Grund erfahren. Jo mei, da muss man dir wohl abolute Basics erklären: Jeder implementiert nur, was ihm wichtig erscheint, ganz egal ob für "offizielle" oder quasi-Standards. Ob nun dem TO geholfen werden kann, hängt einfach davon ab, welcher der in Frage kommenden ID3-Frames für diesen Zweck benutzt wird. Weiss man das, kann man nach einem Player suchen, der mit diesem Frame etwas sinnvolles anfangen kann. Einen muss es ja mindestens geben, das ergibt sich allein aus der Beschreibung des Problems... OK, es gibt natürlich auch eine mögliche Gegenindikation. Nämlich dass der proprietäre Client, der die Kapitel anspringen kann, keinen ID3-Frame verwendet. Das halte ich allerding für recht unwahrscheinlich. Es wird vermutlich eher so sein, dass nur der Export (u.a.) diesen Frame dropped.
Gast
#6517094
Rockbox kann Kapitel per Cue-Sheet (separat oder embedded).
Gast
#6517098
Sorry, hab das "für Linux" vergessen ...
Gast
#6517110
Schon erstaunlich dass so eine (eigentlich wichtige Funktion) gar nicht benutzt oder nur umständlich angeboten wird. Klar, bei Musik-Files braucht man das nicht. Bei Audiobooks wäre es schon sinnvol. Aber wer hört solche Sachem am PC...
Gast
#6517257
c-hater schrieb: > Jeder implementiert nur, was ihm wichtig erscheint, ganz egal ob für > "offizielle" oder quasi-Standards. Falsch. "offizielle" oder quasi-Standards werden immer implementiert, nicht weils der Coder mag, sondern weil er will das die User sein Programm nutzen sollen. Und ein "Das Prg. kann das nicht" ist ein Totschlagargument ein anderen Programm zu nutzen. Rolf M. schrieb: > Schlaumaier schrieb: >> Und wieso muss der TO hier suchen wenn es doch mp3-Player wie Sand am >> Meer gibt. > > Wer hat behauptet, dass es die wie Sand am Meer gäbe? ICH. Weil ich allein bei Android ca. 10 ausprobiert habe bis ich eine gefunden habe was meine besonderen Ansprüche erfüllt. Diese haben aber nix mit ID3 o.s. zu tun sondern wie die Player die Dateien verwalten. Anders ausgedrückt ich mag keine Playlists. alle kalt erwischt schrieb: > Bei Audiobooks wäre es schon sinnvol. Aber wer hört solche Sachem am > PC... Genau und genau deshalb erfüllt mein Player auf den Android-Handy eine wichtige Funktion. Er merkt sich die Position an der ich das Hören abgebrochen habe. Und das nicht nur im Speicher sondern auch nach einen Neustart des Handys. Und das für JEDEN Ordner einzeln. Vorher habe ich ein Mp3-Splitter benutzt und den Player gesagt er soll KEINE Pausen machen. So das ich es scheinbar an einen Stück hören konnte. Das sind zwar nicht die echten Kapitel ist mir schon klar. Aber es ist immerhin eine halbwegs brauchbare Lösung als durch ein mp3-File von 6 Std. sich durch zur clicken und dann zu schätzen wo man war.
Gast
#6517964
alle kalt erwischt schrieb: > Klar, bei Musik-Files braucht man das nicht. Genau das ist der Punkt, warum die meisten Player damit nix anfangen können. Weit, weit überwiegend werden MP3-Player halt zum Musikhören verwendet. > Bei Audiobooks wäre es schon sinnvol. Ja, klar. > Aber wer hört solche Sachem am > PC... Ja, das ist tatsächlich ein Problem. Auf dem PC ist es relativ leicht, diese Funktionalität umzusetzen, für alle relevanten OS. Diese heftigst verkrüppelten APIs der Mobilgeräte machen das aber sehr viel schwieriger, insbesondere dann, wenn der Code auch noch über verschiedene OS hinweg funktionieren soll... c-hater schrieb: >> Bei Audiobooks wäre es schon sinnvol. > > Ja, klar. Werden die nicht in dutzenden einzelnen Files ausgeliefert?! Ich seh hier nur Potential für Podcasts!? Nachtrag: Teo D. schrieb: > Schlaumaier schrieb: >> Was vermutlich der Grund ist, wieso es kein mir und den TO bekannten >> Player gibt der das unterstützt. > > BSPlayer kann das Erst seit V2.76 (2.75.xyz) also noch nich so lange ... denke ich. Teo D. schrieb: > c-hater schrieb: >>> Bei Audiobooks wäre es schon sinnvol. >> >> Ja, klar. > > Werden die nicht in dutzenden einzelnen Files ausgeliefert?! Müssten sie ja nicht, wenn die Player mit Kapiteln umgehen könnten. > Ich seh hier nur Potential für Podcasts!? Warum? Was ist bei denen anders? Rolf M. schrieb: > Teo D. schrieb: >> c-hater schrieb: >>>> Bei Audiobooks wäre es schon sinnvol. >>> >>> Ja, klar. >> >> Werden die nicht in dutzenden einzelnen Files ausgeliefert?! > > Müssten sie ja nicht, wenn die Player mit Kapiteln umgehen könnten. > >> Ich seh hier nur Potential für Podcasts!? > > Warum? Was ist bei denen anders? Ja.... so hab ich mir das zumindest sagen lassen!? Bzw. alle Seiten zu diesem Thema beziehen sich drauf. Wenns nich so is, brauchts dann halt wirklich keine Sa...?-/ PS: Wie zum Teufel muss ich einen µC Programmiren, das er mir einen Ordner (FAT32) mit 01,02,03... benannten Files, identischem Datum u. Uhrzeit, komplett krude sortiert? (NUR Ordner/Files Tags werden NICHT gelesen!) .... Andres aber ähnliches Thema, das mich grad umtreibt... für 30€ ohne gleichwertigen Ersatz in Aussicht <- Übrigens, da würd ich gern hinziehen!³ Teo D. schrieb: >>> Ich seh hier nur Potential für Podcasts!? >> >> Warum? Was ist bei denen anders? > > Ja.... so hab ich mir das zumindest sagen lassen!? Was hast du dir sagen lassen? Dass du es nur für Podcasts sinnvoll finden sollst? Ich würde es für so ziemlich alle längeren mp3-Files für sinnvoll erachten. Teo D. schrieb: > PS: Wie zum Teufel muss ich einen µC Programmiren, das er mir einen > Ordner (FAT32) mit 01,02,03... benannten Files, identischem Datum u. > Uhrzeit, komplett krude sortiert? Dazu musst du ihn ganz einfach so programmieren, dass er die überhaupt nicht sortiert. Dann ist die Reihenfolge die, wie sie im Directory stehen, ganz unabhängig von irgendwelchen Attributen. > .... Andres aber ähnliches Thema, das mich grad umtreibt... für 30€ ohne > gleichwertigen Ersatz in Aussicht <- Übrigens, da würd ich gern > hinziehen!³ Ich hab keine Ahnung, was du damit sagen willst. Rolf M. schrieb: > Was hast du dir sagen lassen? Dass du es nur für Podcasts sinnvoll > finden sollst? Ich würde es für so ziemlich alle längeren mp3-Files für > sinnvoll erachten. Es gibt halt sonst keine.... Und darum gings hier! Rolf M. schrieb: > Dazu musst du ihn ganz einfach so programmieren, dass er die überhaupt > nicht sortiert. Dann ist die Reihenfolge die, wie sie im Directory > stehen, ganz unabhängig von irgendwelchen Attributen. Im "Directory" stehen sie in der richtigen Reihenfolge! Du meintest sicher, wie sie in der FAT anzutreffen sind. Nein, das wars auch nicht. Rolf M. schrieb: >> .... Andres aber ähnliches Thema, das mich grad umtreibt... für 30€ ohne >> gleichwertigen Ersatz in Aussicht <- Übrigens, da würd ich gern >> hinziehen!³ > > Ich hab keine Ahnung, was du damit sagen willst. Unwichtig Teo D. schrieb: > Rolf M. schrieb: >> Dazu musst du ihn ganz einfach so programmieren, dass er die überhaupt >> nicht sortiert. Dann ist die Reihenfolge die, wie sie im Directory >> stehen, ganz unabhängig von irgendwelchen Attributen. > > Im "Directory" stehen sie in der richtigen Reihenfolge! Wie hast du das sichergestellt? In der Regel kann man die Reihenfolge als Anwender nicht direkt beeinflussen. > Du meintest sicher, wie sie in der FAT anzutreffen sind. Nein, in der FAT steht nur die Zuordnung der Sektoren. Im Directory dagegen steht eine unsortierte Liste der Dateien.
Gast
#6518741
Ich würde folgendes probieren. Die mp3-Datei in Audacity einlesen die Text-Datei dazu lesen Die Datei exportieren mit den Textmarkern als Trennung. Datei-Benennung mit Nummerierung vor Text-marken. Das trennt die Datei sauber auf in einzelne Kapitel. Durch die Nummerierung bleibt die Reihenfolge erhalten. Kapitel-Titel werden aus der Textdatei übernommen. Ich weiß nur nicht ob es Audacity auch auf Linux gibt.
Gast
#6519131
Schlaumaier schrieb: > Ich weiß nur nicht ob es Audacity auch auf Linux gibt.
ja
Gast
#6519156
Warum eine weitere Strukturebene einfuehren? Einfach die Dateien auftrennen. Es gibt auch Player, die die Stuecke dann ohne Versatz, knacken, "Faden" usw. abspielen. Also man kann eine MP3 mitten im Wort auftrennen und bemerkt beim Abspielen gar nichts. Rolf M. schrieb: >> Im "Directory" stehen sie in der richtigen Reihenfolge! > > Wie hast du das sichergestellt? In der Regel kann man die Reihenfolge > als Anwender nicht direkt beeinflussen. In dem ich sie in der richtigen Reihenfolge kopiert habe und Total-Commander meint, es hätte geklappt. Rolf M. schrieb: >> Du meintest sicher, wie sie in der FAT anzutreffen sind. > > Nein, in der FAT steht nur die Zuordnung der Sektoren. Im Directory > dagegen steht eine unsortierte Liste der Dateien. Dann war der Programmierer also doch ein Witzbold.... ;) Wie schon geschrieben, ich kann mir da keinen Reim drauf machen.
Gast
#6519189
Teo D. schrieb: > PS: Wie zum Teufel muss ich einen µC Programmiren, das er mir einen > Ordner (FAT32) mit 01,02,03... benannten Files, identischem Datum u. > Uhrzeit, komplett krude sortiert? Das ist einfach: Man muss das garnicht programmieren, sondern einfach nur die Verzeichniseinträge in genau der Reihenfolge verwenden, wie sie im Verzeichnis physisch drinstehen. Da sind sie nämlich nicht sortiert. Die Reihenfolge ergibt sich durch die Reihenfolge der Erzeugung/Löschung von Verzeichniseinträgen, ist also (nach hinreichender Anzahl solcher Vorgänge) quasizufällig.
Gast
#6519338
Naja unter Windows gibt es ein DIRSORT-Programm. Dies habe ich für den mp3-Player (intenso) meiner Schwester schon mal benutzt. Da aber fast jeder Mp3-Player eine Playlist unterstützt wäre es kein großen Aufwand diese Playlist dann zu erstellen so das sie in der richtigen Reihenfolge sind. Unter DOS (Windows CMD) reicht dazu ein einfacher Befehl. Sollte unter Linux auch gehen, kenne ich nur nicht da meinen Erfahrung mit Linux als sehr beschränkt einzustufen sind.
Gast
#6519345
Teo D. schrieb: > PS: Wie zum Teufel muss ich einen µC Programmiren, das er mir einen > Ordner (FAT32) mit 01,02,03... benannten Files, identischem Datum u. > Uhrzeit, komplett krude sortiert? Einfach bei Google nach drivesort (für Windows) suchen. Das ändert Physikalisch die Reihenfolge auf den Datenträger (Bedingung FAT-32). Ist in mein Augen die perfekte Lösung für MC-Benutzte Karten. Schlaumaier schrieb: > Da aber fast > jeder Mp3-Player eine Playlist unterstützt wäre es kein großen Aufwand > diese Playlist dann zu erstellen so das sie in der richtigen Reihenfolge > sind. Ja dieser auch. Aber leider nur 4 Interne und da der ganze Schladeradatz aus ~60 Files besteht..... Schlaumaier schrieb: > Einfach bei Google nach drivesort (für Windows) suchen. Das ändert > Physikalisch die Reihenfolge auf den Datenträger (Bedingung FAT-32). Ist > in mein Augen die perfekte Lösung für MC-Benutzte Karten. Ob das Total-Commander kann weis ich garnicht, werd das Tool mal im Hinterkopf behalten. Allerdings ist die Physikalische-Reihenfolge, wie ich bereits geschrieben hatte, exakt so wie ich sie mir vorstelle, also in der richtigen. PS: Bilder sagen....
Angehängte Dateien:
Gast
#6519593
Teo D. schrieb: > PS: Bilder sagen.... ...Nix. Oder kannst du beweisen oder auch nur irgendwie glaubhaft versichern, dass die gewählte Option wirklich die physische Reihenfolge der Verzeichniseintrage anzeigt? Ich würde das stark bezwiefeln. Mindestens bis zu einem entsprechenden Beweis. Das wäre z.B. ein Hexdump des entsprechenden Directory-Files... c-hater schrieb: > Oder kannst du beweisen oder auch nur irgendwie glaubhaft versichern, > dass die gewählte Option wirklich die physische Reihenfolge der > Verzeichniseintrage anzeigt? Mein Gott, ich komm mir ja vor, wie vor Gericht. Ich "glaube" an meinen Total-Commander....
Angehängte Dateien:
Gast
#6519799
Teo D. schrieb: > Ich "glaube" an meinen Total-Commander.... Ich an meinen auch ;). Aber ich denke der Befehl da ist reinste Anzeige und hat nix mit der echten Struktur zu tun. Jedenfalls unter Windows gibt es kein Befehl der die ECHTE Struktur ändert. Deshalb ja das drivesort. Schlaumaier schrieb: > Ich an meinen auch ;). Aber ich denke der Befehl da ist reinste Anzeige > und hat nix mit der echten Struktur zu tun. Jedenfalls unter Windows > gibt es kein Befehl der die ECHTE Struktur ändert. Deshalb ja das > drivesort. Mal abgesehen von den anderen Unverständlichkeiten deinerseits. Ich hatte das Directory zwischenzeitlich in PR00001 umbenannt! Sorry Kannst du nun etwas mit dem Dump anfangen?!
Gast
#6520191
Teo D. schrieb: > Ich hatte das Directory zwischenzeitlich in PR00001 umbenannt! Sorry Oh, oh. Ich habe mal zwischenzeitlich die Beweismittel verändert/manipuliert, sorry. Aber Herr Richter, ich schwöre, alles war so, wie ich es behauptet habe... Was wird wohl der Richter dazu sagen? c-hater schrieb: > Oh, oh. Ich habe mal zwischenzeitlich die Beweismittel > verändert/manipuliert, sorry. Aber Herr Richter, ich schwöre, alles war > so, wie ich es behauptet habe... Ach weist du was? LMAA :)
Gast
#6540471
Wenn man sich wundert, dass keine der üblichen (Linux) Tools (ffprobe, mpv, vlc, mediainfo) bei einem Podcast (hier 2 Stunden NDR Virus Podcast) nix anzeigt, dann ist da auch nix. Die Kapitelmarken waren im RSS Feed (xml Datei) versteck :-(
Gast
#6544663
Hallo c-hater schrieb: > Genau das ist der Punkt, warum die meisten Player damit nix anfangen > können. Weit, weit überwiegend werden MP3-Player halt zum Musikhören > verwendet. Ist das wirklich so? Immerhin wird für Hörbücher bzw. Streams (?) erstaunlich aufwendige Werbung im klassischen TV gemacht. Auch sind Hörbücher und Hörspiele - leider meist die anstrengenden die zwar "künstlerisch und bedienungstechnisch wertvoll" sein mögen aber so gut wie immer nur wenig Spaß machen durchaus ein Thema in den Kulturprogrammen der öffentlich rechtlichen Radioprogrammen. Auch wenn ich mir anschaue was seit nun (mehr als) 2 Jahrzehnten so an Hörbüchern produziert wird so sind diese kein absolutes Nischenthema mehr und entsprechend nutzbare MP3-Player (egal ob als Programm oder "echter reiner") Audiodateiplayer sollten doch eigentlich verbreiteter sein?! Außerdem wurde die Frage sowohl hier im Forum als auch in so manch anderen schön öfter gestellt, und das nicht erst seit gestern... Realist
Gast
#6544674
Hallo Maxe schrieb: > Warum eine weitere Strukturebene einfuehren? Einfach die Dateien > auftrennen. Es gibt auch Player, die die Stuecke dann ohne Versatz, > knacken, "Faden" usw. abspielen. Also man kann eine MP3 mitten im Wort > auftrennen und bemerkt beim Abspielen gar nichts. Weil es genug Audiobücher gibt die sich über 12h und mehr hinziehen (halt echte Buchlesungen). Denn Herrn der Ringe (als nur ein Beispiel) will wohl niemand freiwillig in (für ihn) sinnvolle Kapitel aufteilen müssen - da ist man froh wenn das schon ein "Profi" gemacht hat. Realist
Gast
#6544697
Realist schrieb: > "künstlerisch und bedienungstechnisch ... bildungstechnisch.... (da meckert aber die Rechtschreibkorrektur....) Als ich neulich einige Hörbücher auf CD nach MP3 konvertieren wollte, stand ich vor einem ähnlichen Problem: Die Kapitelstruktur sollte natürlich erhalten bleiben. Für jedes Kapitel eine eigene MP3-Datei wollte ich vermeiden, schon wegen der Cover-Bilder - die waren bei mir typischerweise um die 500kB gross, bei 80 Kapiteln wären das bereits 40MB verschwendeter Speicherplatz nur durch die redundante Speicherung der Cover in 80 Dateien. Im Endeffekt habe ich als Dateiformat einfach M4B statt MP3 verwendet. Das ist ein von Apple eingeführtes Dateiformat (offenbar einfach eine AAC-Datei mit Metadaten), das Kapitel unterstützt und hauptsächlich für lange Audiodateien wie Hörbücher, Podcasts etc. verwendet wird: https://www.dateiendung.com/format/m4b Die Unterstützung ist natürlich nicht ganz so gut wie bei MP3. Hardware-Player mit M4B-Unterstützung dürfte es nur wenige geben. Bei Software-Playern sieht es deutlich besser aus, vlc bspw. spielt M4B problemlos ab, mplayer scheint M4B ebenfalls zu unterstützen, mehr habe ich bislang nicht ausprobiert. Smartphone-Apps gibt's natürlich auch. Ich habe mir ein Kommandozeilen-Skript geschrieben, um mir das Erstellen von Hörbüchern als M4B-Dateien so einfach wie möglich zu machen. Kann ich bei Bedarf hochladen. Joachim S. schrieb: > Für jedes Kapitel eine eigene MP3-Datei wollte ich vermeiden, schon > wegen der Cover-Bilder - die waren bei mir typischerweise um die 500kB > gross, bei 80 Kapiteln wären das bereits 40MB verschwendeter > Speicherplatz nur durch die redundante Speicherung der Cover in 80 > Dateien. 500k für das Cover ist aber auch schon ziemlich groß. Das könnte man wahrscheinlich mindestens um 80% reduzieren, ohne dass das groß stören würde.
Gast
#6545233
Hm - gibt es einen (nennenswerten) Unterschied zwischen .m4a und .m4b?
Gast
#6545301
8Hz MP3 schrieb im Beitrag #6545233: > Hm - gibt es einen (nennenswerten) Unterschied zwischen .m4a und .m4b? Kernthema -> b kann Kapitelmarken/Lesezeichen.... Joachim S. schrieb: > https://www.dateiendung.com/format/m4b Rolf M. schrieb: > 500k für das Cover ist aber auch schon ziemlich groß. Das könnte man > wahrscheinlich mindestens um 80% reduzieren, ohne dass das groß stören > würde. Sicher. Ich habe mich beim Cover für eine Qualität entschieden, die weiss Gott nicht wirklich nötig ist. Und auch nur, weil bei einer mehrere 100 MB grossen Datei ein paar hundert Kilobyte mehr oder weniger halt kaum noch in's Gewicht fallen. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
