What to do with foreign tunes


#1

I recently just got into fixing my music library and I'm running into a situation, and wanted to know what other people do. I have some Chinese music in my collection, and they are tagged correctly with the Chinese characters, but I don't know if I should keep them that way or change them. I'm curious what other people do when organizing their library. Do you keep the foreign characters? Do you translate them to their English equivalent? Do you change the tags to be something more meaningful to you in English so that you can more easily find them when searching? Or do you do something completely different?

Yes, I am new here...I created an account just so I can ask this question here...:slight_smile:


#2

I have some russian music for example and I keep it as it is, in cyrillic.

Nowdays, it does not pose a problem anymore, even on filesystem level.
And, as I am a bit of "multilingual" person myself, I don't need to transalte them to find them :stuck_out_tongue:

I do have some korean music, but these I have de-translit, because I would be otherwise unable to even search them...

I do use language field as well as specified in id3v2.3 to make my life a bit easier.


#3

For all non-Latin titles, I have added a transliterated title after it according to the ISO-standard.
An example would be:

떳다!!그녀!! (Ddota!! Kunyo!!)
by: 위치스 (Wichiseu)

Although this isn't a perfect solution, as sometimes the title can mix Latin and non-Latin:
Run Free (Swan Dance を 君 と) (wo kimi to)
by: TOKIO

But it is still clear which part is the transliterated portion.


#4

Regardless of the principle contemplations I would like to add the following which I think applies to any information that gets added to a particular field but has a different context if you closely look at it.
In this case language variants are added to a field although in a clean data structure this data should end up in a separate field. I know it is not there, that is why we have to use that clutch.
BUT: If you add semantically different data and in a way split a field in more parts, it would be worthwhile to consider if a unique separator for that purpose should be applied.
In other words: I think that the normal parenthesis is not a good separator as this could be part of the original data. So any other but unique separator should be used, e.g. the |.
So in a title I have the [] to separate the mix or version from the ordinary text, the <> to enclose the featured artist. What else could be there?
Like that
떳다!!그녀!! (Ddota!! Kunyo!!)
Would become
떳다!!그녀!! | Ddota!! Kunyo!!
Just a suggestion.


#5

Having an illegal character in TITLE is bad idea, as you cannot duplicate it in FILENAME


I suggest taking a look at https://en.wikipedia.org/wiki/Geometric_Shapes and
https://en.wikipedia.org/wiki/Block_Elements

They are [I assume] not illegal and can also make a more visual mark than just a simple thin line


#6

True. Yet there are so many characters in ordinary titles that are also not valid for various filesystems (e.g.*, ?) that filenames cannot be used as reliable data storage.
But I agree: if you have the choice why choose a probably invalid character.
But then if you consider the various implications ... why do you suggest characters that can only very awkwardly be entered with the keyboard. My keyboard does not have a single block character on a readymade key.
Perhaps you have an idea that circumvents both drawbacks: valid character for the filename (if this should really be a criterion) and easily entered via the keyboard.


#7

We can use a very simple action to enter such chosen sign

We can also use a very simple action to change something "enterable" from a keyboard like the | into e.g. . And we do not even have to execute it every single time- if you have order and know what you are doing, you can run such an action from time to time on all of your files

As for dealing with the common problem of ? or : in TITLEs and FILENAMEs: Title to Exactly Match Filename [but once again - and order / planning is required among your system / files]


#8

I’m not concerned with file names since I strictly use iTunes for file management as well as listening, and a lot of my fields are more than 40 characters long anyway, so I’m gonna try the pipes character and see how that works. Thanks for the suggestion ohrenkino!

Side note...you mention using brackets to signify versions...I do the same thing too. I’m curious how you would handle an extended version of a remix version, or if you have a short version and long version of a song.

Side note 2...you already posted an example of how you would name a foreign language track, but would you mind posting a couple other examples of some of your track names? I like your ideas you’ve said so far and I’m wondering if I could take what you do and use it to suit my needs.


#9

Almost too much of an honour - but I'll try:
all featured artists are part of the title and are enclosed in <>
e.g
The Beatles: Ain't She Sweet <&Tony Sheridan>
a special version or any kind of extra information is enclosed in [], e.g.
The Beatles: Ain't She Sweet [live extended version] <&Tony Sheridan>

This has the advantage that if you get normal parenthesis () then this does not get confused with other information, so you could have:

The Beatles: Ain't She Sweet (yes, she is) [live extended version] <&Tony Sheridan>

The unique separators make it much easier to extract each piece of information than just plain brackets:
The Beatles: Ain't She Sweet (yes, she is) (live extended version) (&Tony Sheridan)

The ampersand is used to unify the different words in various languages like "featuring", "mit", "avec" etc.

I think that is about it.


#10

I also use different kind of brackets for different kind of information. And also reserve the ( ) for denoting the "original" part of title that was in brackets. Like in Sweet Dreams (Are Made Of This) by Eurythmics


But one big difference: I use ( ) { } [ ] for TITLEs because I also copy them to FILENAMEs - and use the < > in other fields [because those last ones are illegal characters]


#11

I'm from the US and a number of years ago I traveled across Europe and purchased typical music cds in the various countries I visited. I had problems with tags in other languages because I export my tag data and import it into a relational database. The foreign language characters cause formatting problems for my database operations due to my desired db code page, so I used MP3Tag and research the tag data in English and update my tags to my liking. Not exactly the purist approach, but it works for me because it allows me to understand better the music I'm hearing by getting English tags. I can always go back to the original recording if I change my mind. If I can't locate a translation, I remove or replace the original characters with the closest English visual equivalants that do not cause the formatting issues.


#12

Well [assuming e.g. a person is from USA or most part of Europe] it is nice to able to find that piece of music, entering something in English or some other language using a version of latin alphabet- instead of having to deal with some Asian characters which you would not even now how to write down with your keyboard

But even in my native language I can listen to a song over and over and still not understand what it is about [while understanding the words]- or be in a state ignorance, when I think I understand what the title [written down in my native language] really means