Forum>Software>macOS: m4a zu mp3 resultiert in 2 Dateien

macOS: m4a zu mp3 resultiert in 2 Dateien

shooter36416.11.1816:34
Hallo liebe Community,

seit September setzte ich auf macOS und konnte bisher ein Problem nicht lösen.
Mein Autoradio spielt nur .mp3 Dateien von meinem USB Stick ab, daher konvertierte ich meine .m4a Dateien bisher.
Als ich nun auf macOS wechselte suchte ich nach neuer Software. Das Konvertieren klappt auch, am Auto sehe ich dann jedoch immer 2 Dateien pro Song. Die zweite kann hierbei nicht geöffnet werden.
Am Mac kann ich diese auch dann nicht sehen, wenn die versteckten Dateien angezeigt werden.
Anbei ein Bild um das besser zu verdeutlichen.

Habt ihr einen Lösungsansatz oder eine Software die ich hierfür probieren sollte?
0

Kommentare

Apple@Freiburg
Apple@Freiburg16.11.1816:47
shooter364

Das ist die Informationsdatei, in der Songtexte, Cover etc. gespeichert werden.

Vielleicht hilft es den Stick am Mac anzuschließen, versteckte Dateien anzuzeigen und diese dann händisch zu löschen. Wichtig Papierkorb nach dem löschen entleeren, sonst befindet sich dieser auf dem Stick.
+2
MikeMuc16.11.1816:57
Du darfst dich mal über Dateisystem und wie der Mac sie nutzt schlau machen
1. dein Autoradio ist doof weil: Dateien mit einem Punkt vorne dran werden üblicherweise nicht dargestellt. Zumindest ist das die Voreinstellung ei den meisten "anständigen" Computern
2. die "nun unsichtbaren" Dateien enthalten die Daten, die dein Mac problemlos in hfs+ oder APFS problemlos in einer Datei für dich darstellt. Und er ist sogar so schlau das er 2 Dateien im Finder wieder nur als eine darstellt wenn er der Meinung ist die gehören zusammen, selbst wenn du ihm ein Dateisystem vorsetzt welches er nicht ganz so gern mag
3. Wenn du diese Daten löscht, gehen Daten verloren. Du solltest das also lediglich als Einbahnstraße sehen. Machst du sowas zB mit Schriften und denkst, nach dem Löschen der "2. Hälfte" könntest du die auf einem anderen Mac wieder verwenden, dann denkst du falsch.
4. Um deine eigentlich Frage nach Software zu beantworten: zB die hier https://macpaw.com/cleanmydrive Allerdings ohne jegliche Wertung da ich sowas nicht brauche, demzufolge ich weder diese noch andere entsprechende Software nutze und auch nicht bewerten mag / kann. Die unsichtbaren Dateien allerdings als "Hidden Junk" zu bezeichnen halte ich für falsch (s.o) denn bei falschen Einsatz bedeutet das dann klassischen Datenverlust durch Falschinformation.
+3
Deichkind16.11.1817:01
Diese Resourcen-Dateien bekommt man auf MacOS selbst dann nicht zu sehen, wenn man den Finder so konfiguriert, dass die sonstigen versteckten Dateien dargestellt werden. Auf Windows werden sie allerdings dargestellt, sofern Windows entsprechend konfiguriert ist. Dort könnte man die Dateinamen passend sortieren und die Zusatzdateien in einem Rutsch löschen.
+1
aquacosxx
aquacosxx16.11.1817:08
ok, mglw. ein problem. ...aber warum muss es denn heutzutage ein usb stick für mucke im auto sein? nach dem foto sieht es zumindest stark danach aus, als ob es ein moderneres auto audiosystem ist und es mglw. auch bt gibt. warum nicht dein phone (android, ios) nutzen und die musi via bt streamen? ansonsten, s.o.
0
shooter36416.11.1817:12
Vielen Dank für die raschen Erklärungen, ihr habt mir echt weitergeholfen.
Ich wurde nun zunächst die Software von @MikeMuc probieren und euch dann berichten. 😊
Wünsche euch allen ein schönes Wochenende!
0
Waldi
Waldi16.11.1817:23
Eine (zumindest für mich) gute Lösung kann ich anbieten: Die kleine App "Hidden Cleaner" kann im Dock bleiben; und statt dem Auswerfen eines beliebigen Devices, ob Stick oder Karte, über das Icon im Dock ziehen, löscht alle unsichbaren Dateien auf dem Stick, etc, und wirft ihn/es auch aus.
Verwende ich schon seit vielen Jahren, zuletzt auch unter 10.13.6.
+3
Deichkind16.11.1817:31
Eine gleichartige Anfrage gab es bei StackExchange . Demnach kann man mit Hilfe des Befehls 'dot_clean' die ._-Dateien mit den entsprechenden Mutterdateien vereinigen.
'man dot_clean' im Terminalfenster liefert eine Gebrauchsanleitung. Der Befehl wirkt pauschal auf den Inhalt von zu spezifizierenden Verzeichnissen.
+2
RamUwe
RamUwe16.11.1817:46
mag vielleicht für OS-übergreifende Speicher ganz nützlich sein. Funktioniert tadellos. Und man muss es nicht händisch löschen oder via Terminal abschalten.
0
Apple@Freiburg
Apple@Freiburg16.11.1819:20
Stimmt, sehe ich jetzt erst. Wieso denn ein USB-Stick? Das Radio ist doch BlueTooth fähig und man kann damit Musik direkt vom iPhone oder „Smart“-phone wiedergeben.
0
xcomma16.11.1819:41
Apple@Freiburg
Das ist die Informationsdatei, in der Songtexte, Cover etc. gespeichert werden.

Musikinfos werden in ID3 Tags in das MP3 File embedded.


Ist schon eine Weile her, dass ich _xxx Dateien gesehen habe, könnte unter Windows gewesen sein.
IMHO kann man problemlos löschen.
Hab grad nichts auf die Schnelle gefunden bzgl. Erörterung dieser Dateien.
Schätze aber, dass es temporär angelegte Dateien sind, die bei Zugriff (beim Abspielen, Playersoftware abhängig?) entstehen gegebenenfalls. Evtl. entstehen die auch erst als "Beigabe" beim Rippen, wobei m4a-2-mp3 Konvertierung ich nicht als Rippen verstehe.) Wie gesagt, einfach löschen.

shooter364, womit konvertierst du?

Habe neulich .m4a mit Audacity konvertiert. Da kommt nichts anderes ausser .mp3 heraus.
Die obige Beschreibung, dass unter macOS bei MP3 Dateien die _xxx Dateien automatisch ausgeblendet werden, da wäre mal ein weiterführender Link super. Ich finde diese Erklärung aber schon etwas exotisch.
0
bmonno16.11.1820:35
Das sind Dateien, die vom Finder beim Kopieren auf ein Dateisystem ohne Ressourcefork-Fähigkeit, z.b. FAT32, erzeugt werden, so dass beim Zurückkopieren zum Mac die Datei vollständig rekonstruiert werden kann. Nennt sich Apple Double und gehört eigentlich abgeschafft. Solche Dateien existieren auf einem Mac-Filesystem also nicht.
Wenn ich von Windows-System Daten bekomme, habe ich diese Informationen auch nicht, trotzdem funktioniert alles. Reiner, lästiger Sport von Apple, der halt manche Systeme durcheinander bringt.
Kann problemlos gelöscht werden. Bei Netzlaufwerken kann man das Erstellen abstellen.
+3
xcomma16.11.1821:04
xcomma
_xxx Dateien automatisch ausgeblendet werden, da wäre mal ein weiterführender Link super. Ich finde diese Erklärung aber schon etwas exotisch.
Grad nochmal in Ruhe gelesen, sorry, ich hab irgendwie nur _xxx vorher gelesen, nicht ._xxx sowie die Auskunft man könnte diese Dateien nicht sehen.
Ja, .xxx werden automatisch ausgeblendet, auf Terminalebene aber natürlich anzeigbar. .xxx Dateien können sehr unterschiedlicher Herkunft sein, in dem Fall ist die Erklärung von @@bmonno offensichtlich passend.

Im Path Finder kann man sich diese anzeigen lassen. Mittels TinkerTool (oder dem zugrundeliegenden Terminal Befehl) sollten die auch anzeigbar sein im Finder.
-2
MikeMuc16.11.1821:59
climate,
Ich wiederhole mich nur ungern aber wenn du diese Dateien blind löscht dann riskierst du defekte Dateien. Hier in dem speziellen Fall kann man sie löschen, in vielen anderen Fällen besser nicht da dort der Teil der Resourceforks gespeichert wird wenn das Dateisystem sie nicht unterstützt. Nur weil du das nicht zu kennen scheinst solltest du keine Falschinformationen in die Welt setzen.
-3
almdudi
almdudi16.11.1823:37
Nach allem, was ich so weiß, kann man die Dateien durchaus löschen, aber wie genau das funktioniert - keine echte Ahnung. Vor OS X gab es ja immer die Zuordnung "Datei – Ressource fork Datei", heute sollte aber alles wirklich relevante in den Dateien stecken.
Und da es meistens um Musik geht: was steckt denn da in den versteckten Zusatzdateien? Doch höchstens ein Link zu Covern, die nicht in der mp3-Datei stecken - was aber durchaus möglich ist, bei nicht von Apple verkauften Dateien sogar normal.

Warum MikeMuc dafür aber, ohne daß jemand widerspricht, drei Daumen nach unten bekommt… Mehr und mehr vermute ich, daß bei den Daumen nicht Kompetenz eine Rolle spielt, sondern bestenfalls Bauchgefühl.
-1
almdudi
almdudi16.11.1823:43
xcomma
xcomma
_xxx Dateien automatisch ausgeblendet werden, da wäre mal ein weiterführender Link super. Ich finde diese Erklärung aber schon etwas exotisch.
Grad nochmal in Ruhe gelesen, sorry, ich hab irgendwie nur _xxx vorher gelesen, nicht ._xxx sowie die Auskunft man könnte diese Dateien nicht sehen.
Ja, .xxx werden automatisch ausgeblendet, auf Terminalebene aber natürlich anzeigbar. .xxx Dateien können sehr unterschiedlicher Herkunft sein, in dem Fall ist die Erklärung von @@bmonno offensichtlich passend.

Im Path Finder kann man sich diese anzeigen lassen. Mittels TinkerTool (oder dem zugrundeliegenden Terminal Befehl) sollten die auch anzeigbar sein im Finder.
Versteckte Dateien kann man sich so oder so im Finder anzeigen lassen.
Per Tools oder per Terminalbefehl.
Daß es versteckte Dateien gibt, die man da dennoch nicht sieht, wie eben die genannten auf Fremdformaten angelegten, bezweifle ich. Die sind auf HFS+ und kompatiblen einfach nicht vorhanden, deren Funktion übernimmt das System.
Ist aber Halbwissen und Erfahrung.
Im Terminal, also auf der grundlegenden UNIX-Ebene sieht man da nämlich nie zusätzliche Dateien, nicht auf HFS-Laufwerken.
-1
RamUwe
RamUwe16.11.1823:55
almdudi
Warum MikeMuc dafür aber, ohne daß jemand widerspricht, drei Daumen nach unten bekommt… Mehr und mehr vermute ich, daß bei den Daumen nicht Kompetenz eine Rolle spielt, sondern bestenfalls Bauchgefühl.

Ich nehme an, weil der Tonfall die Musik macht. Dass man die Resourcen-Fork-Datei-Leichen ohne Weiteres und bedenkenlos löschen kann, ist jetzt nicht neu. Zumal sie auf nicht Mac-System sinnlos sind und beim Backup stören. Warum die Apple immer noch mitschleppt, ist mir ein Rätsel. climate – wer auch immer das ist, dafür anzupflaumen, er hätte keinen Plan, obwohl MikeMuc davon selber betroffen zu sein scheint, halte ich nicht für die feine Art.
Weia (05.03.2017)
Richtig ist, dass OS X zu Anfangszeiten nicht so recht wusste, wohin Metadaten zu Dateien geschrieben werden sollten. HFS+ hatte kein (jedenfalls kein umfangreiches) Metadatensystem und die auf dem klassischen Mac OS üblichen Resource-Forks im Dateisystem wurden zwar noch verstanden, waren aber auf dem Weg der Ausmusterung, und so landeten einige Metadaten, z.B. die Kommentare zu Dateien, in den .DS_Store-Dateien. Dieses System war sehr fehleranfällig, denn wenn man z.B. eine Datei in einen anderen Ordner verschob, mussten ja die entsprechenden .DS_Store-Einträge in die .DS_Store-Datei des neuen Ordners umkopiert werden. Der Finder machte das, die entsprechenden Unix-Befehle im Terminal aber z.B. nicht. So gingen Kommentare etc. leicht verloren.

Besonders schlimm waren einige Software-Hersteller, denen der rechte OS-X-Durchblick fehlte und die deshalb für ihre Software Installer auslieferten, die es fertig brachten, sämtliche .DS_Store-Dateien im Dateipfad des zu installierenden Programms (also z.B. zwei .DS_Store-Dateien bei dem Pfad /Programme/Dienstprogramme/) mit den .DS_Store-Dateien desjenigen Rechners zu überschreiben, auf dem der Installer erstellt wurde. Und schwups, waren die eigenen Kommentare gelöscht …

Mit der Einführung von Spotlight und Time Machine in OS X 10.4 und 10.5 wurde HFS+ aber so aufgebohrt, dass es rundum Metadaten-fähig ist. Seitdem befinden sich die Metadaten (Kommentare, Tags, …) direkt im Dateisystem und nicht mehr in der .DS_Store-Datei des Ordners.

Man kann sich das leicht im Terminal mit dem Befehl xattr (extended attributes) und der Option -l (für list) ansehen:

xattr -l /Pfad/zu/der/Datei

In den .DS_Store-Dateien befinden sich jetzt ausschließlich ordnerspezifische Finder-Einstellungen – welche Ansicht (Spalten, Liste, …), Größe des Finder-Fensters usw. und insbesondere alles, was man im Dialog Darstellungsoptionen (Command-J) so einstellen kann.
0
Krypton16.11.1823:56
Im Prinzip wurde schon alles gesagt. Die ._xxx Dateien können Daten enthalten, die der Mac an eine Datei anflanscht, unter Windows aber so nicht an die Datei geklebt werden können. Daher speichert der Mac dies als Extra-Datei (versteckt) ab. In 99.9 % der Fälle kann man die heute löschen. Ausnahmen sind (wie oben erwähnt) uralte Mac Postscript Schriften und bestimmte Programme des alten Mac OS (Mac OS …7, 8, 9). Damit hat man heute aber üblicherweise keine Berührung mehr und als Mac Neuling sowieso nicht.

Oben wurde der Hidden-Cleaner empfohlen. Der ist schon ganz gut, es gibt aber noch eine leicht verbesserte Version: Hidden Cleaner improved (HiM), welche auch kostenlos erhältilch ist
Der Vorgang ist folgender: Du speicherst alles normal auf den USB-Stick und ziehst den Stick anstatt auf das Auswurfsymbol/Papierkorb einfach auf das Programmfenster (Drag & Drop). Dieses löscht die unerwünschten Dateien und wirft den Stick aus. Dann läuft er wunderbar im Auto.

Dieses Vorgehen sorgt dafür, dass der Mac-Finder die Zusatzdateien nicht mehr anlegen kann. Das kann passieren, wenn du den Stick das nächste mal in den Mac steckst und einige der Dateien anklickst oder abspielst. Dann werden die unsichtbaren Dateien wieder erstellt und müssen wieder mit HiddenCleaner oder HiM gelöscht werden.
+2
AMThie
AMThie17.11.1802:10
187
0
sierkb17.11.1803:05
<OT>
RamUwe
Dass man die Resourcen-Fork-Datei-Leichen ohne Weiteres und bedenkenlos löschen kann, ist jetzt nicht neu. Zumal sie auf nicht Mac-System sinnlos sind und beim Backup stören. Warum die Apple immer noch mitschleppt, ist mir ein Rätsel.

Nicht nur Dir ist das ein Rätsel, warum Apple sich dessen nicht schon längst entledigt bzw. das abgestellt hat. Zumal die exzessive automatische Erstellung von Resource-Forks bzw. .DS_Store-Dateien offenbar ein langjähriger immer noch ungefixter Bug und darüber hinaus ein (vermeidbares) Sicherheitsrisiko ist, weil darin sehr redselig reichhaltige Infos bzw. Meta-Infos drinstehen, die man da eigentlich nicht drin wissen und erst recht nicht weitergeben will (soviel dann auch zum Thema: "Wir nehmen Sicherheit und Datenschutz super ernst"…):

Golem (14.03.2018): Websicherheit: Apple-Datei auf Webservern verrät Verzeichnisinhalte
Mittels Parser lassen sich aus .DS_Store-Dateien sensible Informationen auslesen. Das Projekt Internetwache.org hat sich die proprietäre Lösung von Apple genauer angeschaut - und Erstaunliches zutage gefördert.
Golem, 14.03.2018
[…]
Einer der Erfinder von .DS_Store, Arno Gourdol entschuldigt sich in einem Blogpost aus dem Jahr 2006 dafür, dass zum einen der Name nicht besonders gut gewählt sei, zum anderen die massenhafte Erstellung von .DS_Store-Dateien nicht beabsichtigt, sondern ein (mindestens seit 1999/2000 bestehender) Bug sei, der von Apple bis heute offenbar leider immer noch nicht gefixt sei. Seiner Aussage nach sollte die Datei ursprünglich nur erstellt werden, wenn Nutzer tatsächliche Änderungen in einem Ordner vornehmen. Allerdings erfolgt die Erstellung oftmals schon bei Betrachtung von Verzeichnissen.
[…]

Arno Gourdol (01.10.2006): On the origins of .DS_Store
If you are a Mac user, or if you have transfered files from Mac to Windows, you’re probably familiar with .DS_Store files. But where does this name come from? (Arno Gourdol, lead Web Platform and Authoring team at Adobe; Prior to joining Adobe in 2001 member of the User Interface team at Apple that conceived, designed and implemented Aqua, the user interface of Mac OS X, 1999 technical lead for the Mac OS X Finder at Apple)

Internetwache.org (12.03.2018): Analyse der .DS_Store-Datei in den Alexa Top 1 Millionen

Sebastian Neef - 0day.work (03/2018): Parsing the .DS_Store file format

Adobe KB: Entfernen von .DS_Store-Dateien von Mac OS X

Apple Support: Mac OS X v10.4 and later: How to prevent .DS_Store file creation over network connections
This is an advanced article that contains information about preventing .DS_Store file creation over network connections.

</OT>
+2
Waldi
Waldi17.11.1808:24
Krypton
Danke für deine ausführliche Erklärung.
Meiner Erfahrung nach, ist das auch die einzige sinnvolle Möglichkeit, USB-Sticks und dergleichen auf Nicht-Mac-Geräten problemlos abzuspielen.
(Alle weiteren Auslassungen in diesem Thread sind auch richtig, gehen aber am Thema vorbei.)
-1
RamUwe
RamUwe17.11.1808:27
Waldi
(Alle weiteren Auslassungen in diesem Thread sind auch richtig, gehen aber am Thema vorbei.)

Ja, genau, Waldi

+1

Kommentieren

Sie müssen sich einloggen, um sich an einer Diskussion beteiligen zu können.

OK MacTechNews.de verwendet Cookies unter anderem für personalisierte Inhalte, Seitenanalyse und bei der Auslieferung von Google-Anzeigen. Dies war zwar schon immer so, auf Wunsch der EU muss nun jedoch explizit darauf hingewiesen werden. Durch Nutzung der Website erklären Sie sich damit einverstanden. Weitere Informationen