Synology-Forum.nl
Algemeen => The lounge => Topic gestart door: Sylvester op 26 november 2018, 20:26:22
-
(Ik zet het maar in de lounge want het is volgens mij niet specifiek voor een bepaald board)
Phu.... :o hoe moet ik dit gaan uitleggen?
Ik probeer... zeer ingewikkeld....
(Dit is een test buiten mij vraag van Audio station om, die ik elders heb geplaatst. Daar heeft het niks mee te maken)
Ik heb op een share een aantal iTunes libraries staan. Dat is een map met daarin album artwork, iTunes Library, iTunes Library.xml, iTunes media, enz... Dus de complete map zoals iTunes die aanmaakt.
Ik kan die vanop mijn Mac netjes opstarten : optie toets inhouden bij het starten van iTunes. Hij vraagt dan waar de library is. Ik duid die map/library op die share aan en hij start op.
Alles werkt.
Ik wilde een aantal iTunes libraries terug op mijn Mac zetten want dat werkt nog altijd veel sneller dan via de NAS, maar de schijf in mijn MacBook Pro is niet groot genoeg, het zijn omvangrijke libraries met duizenden nummers. Nu is het mogelijk om in iTunes alles op je Mac te zetten BEHALVE de muziekmap waar fysiek alle nummers zitten. Die kan je op een netwerk volume of NAS zetten. Dat werkt ook heel snel.
Dus ik heb dat gedaan voor een aantal libraries : de volledige library map op de mac BEHALVE de omvangrijke muziekmap, die heb ik in de 'music' share gezet (de default map die DSM zelf aanmaakt). Alles werkt prima. Zo heb ik 5 libraries werkende, werkt perfect.
Dat ik die in de music map wil, heeft een bedoeling.
Nu komt het.
Ik heb één kleine library waar veel duitse muziek in zit. Dat zijn soms namen met een duits 'umlaut' teken zoals : ü
Als ik iTunes gebruik zoals de eerste methode (ALLES op de NAS op een aparte share) werkt het goed. De nummers met vreemde tekens worden ook herkend.
Als ik iTunes gebruik zoals de tweede methode (Alles op de Mac, muziek map op de NAS in de 'music' map) werken de nummers met een umlaut niet. Hij zegt dat hij ze niet vindt. Als ik naar de originelen in de 'music' map ga kijken zijn die inderdaad visueel verdwenen ONDANKS dat ik ze bij het kopiëren wél heb zien staan. Als ik opnieuw het nummer erin wil kopiëren zegt hij dat het niet gaat want het staat er al.
Heel vreemd dus... Alle nummers met een 'umlaut' verdwijnen visueel maar zijn er nog.
Nog vreemder is dit :
ik heb een andere zeer omvangrijke library met ook een paar nummers waarin een 'umlaut' staat. Zelfde principe. En toch werkt dat nummer wel.
Voila, hij die deze regel leest heeft de moed gehad om tot hier te lezen. Proficiat en dank...
Ik zie het probleem alleszins niet.
> edit : ik zie het probleem wel, maar de oorzaak niet.
-
Probleem is dat alleen de eerste 127 characters uit de ascii set gestandaardiseerd zijn. Een ü hoort er niet bij. Nu zijn er diverse coderingen om een ü weer te geven. Als degene die schrijft een andere codering gebruikt dan die leest, heb je een probleem en praat men langs elkaar heen.
Het wordt tijd dat iedereen overstapt op unicode (https://www.unicode.org). Dan praat iedereen weer dezelfde taal.
Voor jou nu geen oplossing.
-
Dus eigenlijk hetzelfde probleem als mijn andere vraag ivm die M3U file.
-
Het wordt tijd dat iedereen overstapt op unicode (https://www.unicode.org). Dan praat iedereen weer dezelfde taal.
Tegenwoordig ondersteund DSM standaard unicode voor het opslaan van files echter, dat geldt niet voor "muziekmetadata-indexering" dus, Audio Station:
[attach=1]
DSM Help geeft dan aan:
Codepagina
Voor toepassingen die niet-Unicodereeksen omzetten in Unicode, zoals de FTP-service, UPnP-ondersteuning, muziekmetadata-indexering, moet u de correcte codepagina selecteren in het vervolgkeuzemenu Codepagina
Dus, wat @Briolet al aangaf: "Voor jou nu geen oplossing."
-
Audio Station en ook de playlist ondersteund wel degelijk gewoon unicode (ofwel utf-8).
Ik heb verschillende muziekbestanden met accenten en umlauts erin en die worden prima weergegeven.
Het probleem zit hem in de Windows omgeving, daar wordt geen utf-8 gebruikt, maar enkel 8 bits ascii in combinatie met een codepage.
Afhankelijk welke codepage er ingesteld staat betekent de codes waarin het 8ste bit gezet wordt iets anders.
Terwijl bij utf-8 alles boven de standaard ascii codes met 2 bytes weergegeven worden.
Als je dus een bestand hebt waarvan de naam gecodeerd is volgens de Windows codepage standaard en je zet die gewoon over naar je Nas dan is er niets aan de hand als alles uit simpele ascii codes bestaat.
Het gaat mis als er special tekens in de naam zitten.
Stel dat het eerste karakter van de naam een e met umlaut is, dan wordt dat in Windows gecodeerd met 1 byte en wel iets tussen 128 en 225 (ofwel het 8ste bit is gezet).
Een utf-8 omgeving ziet dat het 8ste bit gezet is en denkt dus dat de eerste twee bytes de echte code is.
Je snapt dat zoiets heel vreemde resultaten kan opleveren inclusief niet bestaande codes waar Linux dan over struikelt.
Als je zo'n bestand normaal via een netwerk share overzet is er niets aan de hand want SMB(aan de windows kant) en Samba aan de Linux kant snappen dit ne doen een nette conversie.
De problemen ontstaan als je bijvoorbeeld de bestanden in een zip of rar stopt en deze op de Nas zelf uitpakt, dan is niet meer bekent met welke codering de namen zijn aangemaakt en kan er dus niet geconverteerd worden.
Zo zijn er nog wel een aantal manieren dat het mis kan gaan, maar de bron is altijd het verschil tussen utf-8 en codepages.
En ja het zou fijn zijn als de codepages verdwijnen, maar ik vrees dat we eeuwig ermee opgescheept blijven.
Ik heb al eens een python programmaatje geschreven die poogt verkeerd omgezette bestandsnamen te corrigeren maar het is een lastige klus door het verschil in 1 byte en 2 bye coderingen, behalve voor de standaard ascii codes.
Ik zal van de week nog wel eens kijken waar ik het heb liggen en hoe goed het is (voortschreident inzicht he).
-
Wat heb ik hier geleerd? Dat ik het complex vind en dat jij er alleszins veel meer van kent dan ik.
Ik snap wel ongeveer wat je bedoelt, maar ik krijgt dat op mijn eigen niet opgelost.
Eigenlijk spijtig dat er zoveel uitzonderingen en afwijkingen zijn. Ben ik dan de eerste die hiermee problemen heeft of ben ik iemand die weer vanalles wil en test wat de meesten niet doen?
-
Het is ook complex en je bent echt niet de eerste die er tegenaan loopt.
Maar doordat het beperkt blijft tot namen met speciale karakters is de aandacht niet heel groot.
En vanuit de Engels/Amerikaanse hoek is er geen aandacht want daar worden geen speciale karakters gebruikt.
Ik ben er zelf tegenaan gelopen door mijn eigen applicatie autosub en het duurde wel evenvoor ik wist hoe het in elkaar zat.
-
Op betterexplained.com (https://betterexplained.com/articles/unicode/) gaat men duidelijk in op de verschillende coderingen. En ook hoe het echt opgeslagen wordt, want dat mist soms in de uitleg.
Silvester, volgens mij was je mac gebruiker. Dan moet je rechtsboven in de menubalk maar eens "Toon Emoji en Symbolen" openen. Alle tekens daar zijn unicode tekens. Standaard laat hij niet alles zien, maar linksboven in het window zit een settings knop. Kies daar "Pas lijst aan…". Helemaal onderaan staan de code tabellen. Kies daar "Unicode". Dan heb je plots toegang tot alle unicode tekens die gedefinieerd zijn.
[attachimg=1]
De ü wordt in unicode dan als "C3BC" op schijf opgeslagen bij UTF-8 codering. Of soms als "BCC3" (Big and Little endian versies om het lekker ingewikkeld te maken)
In elk geval gaat het mis als het programma denkt dat hij een unicode tekst te decoderen, terwijl er een andere codering gebruikt was.
-
Ach ja, Het eeuwenoude UTF-8 probleem.
Zolang ik al in de automatisering werkzaam ben kom ik dit fenomeen tegen bij conversies en koppelingen tussen systemen.
We hebben vandaag een robot op Mars neergezet, maar een simpel codepage probleem laten we 30 jaar liggen ;-)
Peter
-
Het basisprobleem is dus dat iTunes de files na het verplaatsen van de muziekfiles naar de NAS niet meer kan vinden omdat de files op de NAS een iets andere naamgeving krijgen.
Snelste oplossing is om na het kopiëren van de muziekfiles naar de NAS de iTunes bibliotheek opnieuw aan te maken.
Of:
- Verander in iTunes de locatie waar de muziek files moeten worden opgeslagen van de originele locatie naar de nieuwe NAS locatie.
- Kies dan in iTunes de optie "Consolidate library" (de nederlandse kreet weet ik zo niet uit mijn hoofd).
Dan zal iTunes de opbouw van de muziek files controleren en, omdat je de locatie hebt aangepast, automatisch alle files van de originele locatie naar de NAS locatie kopiëren.
-
Het basisprobleem is dus dat iTunes de files na het verplaatsen van de muziekfiles naar de NAS niet meer kan vinden omdat de files op de NAS een iets andere naamgeving krijgen.
Het rare is dat de iTunes libraries oorspronkelijk allemaal op de NAS stonden, op een share (niet de 'music' map). Daar werkten ze wel volledig, maar dit principe werkt zeer traag. Vandaar mijn omschakeling om de libraries op mijn Mac te zetten en de muziekmap naar een ander volume, in dit geval een NAS. Binnen iTunes werkt dit principe 100%, of zou toch moeten werken.
Ik ga eerlijk zijn. Ik ben van de 'oude stempel' zoals ze zeggen. Ik heb nog die dingen geleerd zoals ASCII, sets, codering enz...
De uitleg die Briolet aangeeft (betterexplained) begrijp ik wel ongeveer, allé het verhaal van het luiden en de klepel.
Ik ben toch gestopt in het midden van de tekst en ben overgeschakeld op 'diagonaal' lezen ipv links-rechts-links. Mijn grijze cellen zijn niet overclocked dus ze kunnen minder goed mee...
Dit terzijde, ben ik nu toch aan het peinzen over het feit dat ik wél een library heb die op precies dezelfde manier is behandeld en op dezelfde plaats staat, en waar wél letters met een umlaut in staan. En de muziek werkt wel.
Het enige verschil is de omvang van de library, deze is een factor 1000 groter. Maar dat mag volgens mij geen verschil uitmaken.
Ik ga me toch nog eens hierop focussen.
Ik ga nog eens alles bekijken straks, nu effe arbeit machen.
-
Nee het basis probleem is dat bij de eerste methode alles op de Nas staat en dan werkt het prima.
Bij de tweede methode staat alleen de echte muziek bestanden op de Nas en dan doet iTunes er iets mee waardoor ze op zowel de Nas als de in iTunes niet meer zichtbaar zijn.
iTunes doet dus iets met die bestandsnamen.
Normaal gesproken zou dit geen problemen met codering moeten opleveren, want zowel de Mac als de Nas gebruiken utf-8 als codering.
Dit is speculatie, maar ik denk dat er dit gebeurd:
Blijkbaar denkt iTunes onterecht dat bij de tweede methode de coderingen geen utf-8 is en gaat dan zelf coderen.
Hij probeert dan utf-8 naar weer naar utf-8 te converteren, maar met een codepage naar utf-8 converting en dan is alles ineens weg.
-
Pfff... ik heb toch een gat in m'n grijze cellen.
Toch vreemd, want zelfs zonder tussenkomst van iTunes loopt het fout. (zie ook ander topic (https://www.synology-forum.nl/audio-station/audiostation-m3u-afspeellijsten-importeren-lukt-niet/msg258090/#msg258090))
Als ik een CD in de music map zet waar een trema in voorkomt (of umlaut in het duits) en ik plaats die in een afspeellijst, dan staan alle nummers in de lijst met een rood kruis ervoor.
Als ik die letter met een trema vervang door een gewone letter dan gaat alles goed.
-
Geen idee wat het is.
Dat probleem doet zich bij mijn audio station niet voor.
Ik heb het gisteren nog geprobeert en het werkt allemaal prima.
Het enige verschil is dat ik de muziek vanaf mijn PC op een smb share zet.
Gebruik jij soms afp op je mac?
-
Op betterexplained.com (https://betterexplained.com/articles/unicode/) gaat men duidelijk in op de verschillende coderingen.
Daar heb ik toch heel wat meer geleerd over hoe het ook echt gecodeerd opgeslagen wordt. Als ik dat zo lees, met die UTF headers, zou het geen probleem moeten zijn om unicode en ascii door elkaar te gebruiken. In het begin staat de header.
Nu de praktijk. Als ik in de mac-teksteditor een platte tekst opsla is het wel UTF-8 geformatteerd, maar de twee header bytes worden niet weggeschreven. Als ik de file in UTF-16 opsla staan de twee header bytes er wel.
Nu mijn code editor gepakt. (textwrangler). Die bewaard ook standaard in UTF-8, maar schrijft standaard ook geen BOM-header weg. Bij UTF-16 wel, net als de mac tekst editor. Daar zijn echter wel extra opties om UTF-8 met of UTF-16 zonder BOM weg te schrijven. Ik kan zelfs voor little endian met of zonder BOM kiezen.
Dat er zoveel keuzes zijn, geeft waarschijnlijk aan dat ieder systeem dit ook verschillend opslaat. En als utf-8 standaard geen BOM header krijgt, kan het systeem inderdaad nooit met zekerheid bepalen of dit UTF-8 gecodeerd is. De mac zal dit gewoon aannemen en een anders gecodeerde ü zal mis-geïnterpreteerd worden.
-
Er zijn wel verschillende formaten unicode, echter er is maar een utf-8 en dat is de standaard geworden buiten de Windows wereld.
Dus utf-2, utf-16, little en- big endian kun je allemaal vergeten, die worden nergens meer toegepast.
Een BOM wordt tegenwoordig ook nog zelden aan een bestand toegevoegd, omdat heel veel programmatuur geen BOM verwacht en dat gewoon als data interpreteert en omdat het nog steeds geen zekerheid geeft omdat de BOM code ook gewoon data kan zijn.
BOM was een goed idee maar is ook mislukt vanwege de historie die nu eenmaal bestaat.
Eigenlijk verwacht heel veel programmatuur enkel ASCII en dat is de reden waarom in utf-8 dat gelijk gehouden is.
Verder helpt een BOM je helemaal niets als je het over gecodeerde strings hebt zoals bestandnamen, daar kun je geen BOM aan toevoegen.
Gelukkig heeft zelf Microsoft het licht gezien en ondersteund tegenwoordig overal utf-8 en willen ook die richting op maar zitten ook aan de historie vast.
-
Als ik nu eens het licht zag.... ::) ;D
-
OK, ik denk dat ik eruit ben.
Nog even in kort herhalen: iTunes library (met muziekmap) stond volledig op een share op Synology. De bedoeling was om de iTunes library op de interne HD van mijn Mac te zetten en alleen de muziekmap in het volume 'music' van de NAS. Technisch kan dat dus, iTunes voorziet dat.
Ik kopieer de volledig library met muziek op de interne HD, daarna maak ik op de share 'music' een map aan. Ik duid in iTunes aan dat dit in het vervolg de muziekmap wordt.
Daarna verzamel ik in iTunes de muziek, dat wil zeggen dat iTunes de muziek zelf volledig overzet van de interne HD naar die map op de share 'music'.
Daarna verwijder ik de muziekmap van iTunes op de interne HD. Vanaf nu kan ik dus de bibliotheek opstarten vanaf mijn interne HD en gaat hij de muzieknummers zelf ophalen vanaf de map 'music' op de NAS.
Tot zover is NIETS gewijzigd met mijn voorgaande testen.
Wat heb ik wél veranderd? Ik heb de desbetreffende volumes van de NAS gemount als AFP, dus niet als SMB.
Héél vreemd, want ik dacht als je in een finder venster van de Mac in de linker navigatiekolom een volume van de NAS ophaalt, dat dat altijd AFP is. Blijkbaar is dat bij mij altijd SMB.
Dus als ik zorg dat alles heen en weer gekopieerd wordt onder AFP, loopt alles goed. Alle iTunes nummers inclusief die met duitse umlaut en andere vreemde tekens blijven werken.
-
Conclusie is dan:
iTunes kan niet fatsoenlijk met een SMB share om kan gaan en denkt dat de bestanden daar een Windows codepage codering hebben en die onterecht probeert om te zetten naar utf-8 terwijl het al utf-8 is.
-
Dat zou inderdaad kunnen. Maar geen probleem, ik kan het probleem omzeilen.
Voorlopig ben ik blij. ;D
Nu ga ik me nog eens verdiepen in het probleem met de afspeellijsten in Audio Station.
-
…Héél vreemd, want ik dacht als je in een finder venster van de Mac in de linker navigatiekolom een volume van de NAS ophaalt, dat dat altijd AFP is. Blijkbaar is dat bij mij altijd SMB.…
Sinds Sierra of El Capitan heeft de Mac een voorkeur van SMB boven AFP.
Je kunt wel een share naar de linkerkant van een finder venster slepen (bij favorieten). Je hebt daar dan een snelkoppeling die de share met het gebruikte protocol opent. Je hebt dan wel direct afp.
-
Ha inderdaad. Dat had ik moeten weten