태그(음악)

1. 소개2. 역사3. 태그의 구조

3.1. 태그 이름 vs 필드 이름3.2. 주로 쓰이는 태그3.3. 덜 자주 쓰이는 태그

4. 한 태그에 여러 항목 넣기

4.1. 중복 필드 사용4.2. 구분자 사용

5. 태그 규격들

5.1. ID3

6. 컨테이너 오디오 파일7. 기타

1. 소개

디지털 음원 파일에 기록되는 메타데이터로, 음악의 제목이나 아티스트, 작곡가, 앨범 아트 등의 정보를 포함한다. 이를 활용해 음원의 검색과 정렬을 수월히 할 수 있다.

태그의 규격은 음악 파일의 종류마다 다르다. MP3의 경우 ID3가 표준이다, 간혹 Monkey's Audio 용으로 만들었던 ape 태그와 병행하기도 한다. OGG Vorbis와 FLAC 의 경우 Vorbis Comment를, m4a는 ISO-BMFF 컨테이너의 메타데이터 방식을, mka와 webm은 마트료시카 컨테이너의 메타데이터 방식을 쓴다. AAC같이 컨테이너 밖으로 빠져나온 음원은 ID3를 붙여 관리할 수 있다.

저장되어 있는 방식만큼이나 태그를 읽는 방식도 중요한데, 미디어 플레이어마다 판이하게 다르기 때문에 흔하게 쓰이는 태그 몇몇(ID3, ISO-BMFF)을 제외하면 호환성이 많이 떨어진다.

윈도의 탐색기나, 대부분의 미디어 플레이어와 편집 프로그램들은 음악 파일의 태그를 수정할 수 있으나, 보통 사용자가 깊게 공부하지 않고도 쉽게 쓸 수 있는 수준인 경우가 많아서 호환성은 더 떨어진다. 태그를 원하는 대로 사용하려면 mp3tag 등의 전용 프로그램과, 태그를 원하는 대로 보여줄 수 있는 foobar2000과 같은 미디어 플레이어를 쓰는 것이 편리하다.

2. 역사

디지털 음원의 초창기에는 태그가 자주 쓰이지 않았다. 파일의 양도 그리 많지 않았고, 디렉터리나 파일 이름만 가지고도 음악 파일을 관리할 수 있었기 때문이었다. 그러나 음원의 양이 많아지고, 아티스트가 자기 노래의 장르 변화를 몰색하고(발라드가수가 EDM가수가 된다던가), 가수 그룹이 해체되고 솔로활동에 나서거나, 각종 콜라보 및 컴필레이션 음반 등의 출시 등으로 각종 사유가 발생하면 기존의 간단한 체계로는 음원 정리가 너무 복잡해지기 때문에 음원에 태그의 형태로 메타데이터를 넣게 되었다.

태그 중에 가장 널리 쓰이는 것은 MP3 파일에 사용하는 ID3이다. 초기 버전인 ID3v1의 경우에는 간단하게 파일 맨 끝에 정해진 크기의 꼬리표를 붙이는 방식이었다. 기존 파일에 추가 정보를 붙이는 것이라 뒷부분에 붙었을 듯 한데, 이로서 태그를 못 읽는 당시의 대다수 (구형)기기가 태그를 노래로 인식하고 연주하려 한다던가 파일을 음악파일로 인식하지 못하고 에러를 내는 상황을 막을 수 있으며, 태그를 수정했을 때 파일 앞부분부터 전체를 갈아엎지 않고 뒷부분만 살짝 고치면 되는 효율성 때문이었다. 그러나 ID3v2에서는 태그 영역이 파일 앞쪽으로 이동했는데, 스트리밍에서 파일이 모두 전송되지 않아도 음악정보를 먼저 받을 수 있기 때문이다. 좀 더 융통성있게 (글자수 제한 적게) 정보를 기록할 수 있게 태그 구조도 바뀌었다.

기존의 폴더와 파일이름을 이용하는 방법은 태그를 사용하는 것에 비해 아주 간단하기 때문에 오랫동안 쓰여 왔는데, 태그의 사용율을 크게 높인 주역 중 하나는 아이팟과 아이튠즈로 볼 수 있다. 아이팟은 아주 큰 시장인 북미를 비롯해 세계적으로도 크게 성공했는데, 아이튠즈와 아이팟은 다른 미디어 플레이어들이나 휴대용 MP3 플레이어가 당연하게 지원하던 폴더 구조를 전혀 지원하지 않는다. 아이튠즈는 라이브러리에 음악을 추가하면 어디에 있는지는 완전히 무시하고, 파일의 태그만을 읽어서 아티스트/앨범/장르 등등으로 구분하도록 되어있다. 태그가 없는 파일이라면 딸랑 파일 제목만 제목 태그에 들어간다. 이처럼 태그를 사용하지 않을 수 없는 구조인데다가, 아이팟을 출시할 때부터 야심차게 준비한 iTunes Store에서 구매한 음악은 앨범 아트를 비롯한 태그가 잘 달려있고, 또 사용해보니 많은 양의 음악을 정리하는데 꽤 괜찮았기 때문에 태그의 사용이 늘었다.

CD를 리핑하던 시절에는 태그를 직접 달아야 했으니 그렇게 하지 않고 폴더로 정리하는 경우도 많았지만, 디지털 음원의 시대가 되자 구매한 음원에 이미 태그가 잘 정리되어 있기 때문에 태그의 사용이 더 일반화되었다.

스마트폰을 비롯해 요즘 음악 재생 프로그램들은 태그 정보 중심으로 음원을 정리해 보여주는 것이 기본으로, 자기 편의를 위해 음악의 태그 정보를 수정하는 사람이 늘었다. 표기가 다른 내용을 통일시켜주는 것 뿐 아니라[1], 외국어( ASCII가 아닌 중국어, 일본어, 한국어) 음악의 경우엔 인코딩문제로 글자가 자주 깨지니까 수정해 줄 수 밖에 없다.

3. 태그의 구조

대부분의 태그는 여러 개의 이름과 데이터 짝(필드)으로 이루어져 있다. 예를 들면 '아티스트=비틀즈','제목=Something'과 같은 식으로 되어 있다.

요즈음의 태그 규격들은 임의의 필드 이름과 임의 길이의 데이터를 지원하지만, ID3v1과 같은 경우 필드 개수와 종류가 정해져 있고 데이터의 길이 또한 정해져 있었다. 또한 임의의 필드 이름을 태그로 저장할 수 있다는 것 뿐이지, 그것을 읽어들이는 것은 미디어 플레이어를 만드는 사람 마음대로다.

3.1. 태그 이름 vs 필드 이름

태그 규격의 종류별 필드 비교 테이블, id3v2.4 프레임

태그 종류마다 필드 이름의 표준이 다르다. 즉 플레이어에서 보이는 태그의 이름과, 그 태그가 실제 저장될 때의 필드의 이름은 다르다는 것을 알아둘 필요가 있다. 예를 들어 디스크에서 트랙의 위치인 트랙 번호를 나타내는 필드는 ID3v2.3에서 TRCK, APEv2에서는 Track이고, MP4 컨테이너에서는 trkn로 저장된다. 문제를 더 복잡하게 하는 것은 비표준 필드들인데, 예를 들어 ID3v2.3의 표준에만 있는 필드를 MP4 컨테이너에서 쓰려면 적절한 이름을 임의로 만들어 쓰거나, 사실상 표준으로 쓰이는 것이 있는지 직접 인터넷을 뒤져야만 한다. 여러 종류의 음악 파일을 관리하고 편집하는 프로그램이라면 이 다양한 이름들을 묶어 적절한 대표 이름으로 표시해주지만, 그것도 개발자 마음대로이기 때문에 혼동이 생기기 쉽다.

불법 다운로드한 파일들에 이상한 태그들이 붙어있게 되는 주범이다. 대부분의 사용자는 mp3tag 같은 전용 프로그램까지 사용하지는 않고, 탐색기나 미디어 플레이어에서 태그를 수정하게 마련인데, 이 과정에서 사용자가 고의적이지 않은 트롤링을 하게 되는 경우도 많지만, 실수하지 않더라도 프로그램의 구현이 잘못되어 있는 경우도 많다. 대부분 분류를 "똑똑하게" 해주려다가 말아먹는 경우이다.

예를 들어 다운로드받은 음악 파일 중에는 아티스트 태그가 Various Artists로 되어 있는 경우가 아주 흔하다. 아티스트 태그가 지정되지 않은 음악 파일을 읽은 미디어 플레이어가 아티스트 태그가 비어있는 꼴을 보지 못하고 Various Artists를 채워넣었다가, 사용자가 그 상태에서 태그를 저장하면서 그대로 아티스트가 Various Artists로 저장되는 경우이다. 4자리여야 하는 연도에 8자리 연월일이 들어가 있는 경우가 많은 것도 미디어 플레이어가 두 가지를 명확히 구분하지 않고 하나로 퉁쳐서 보여주는 경우가 많기 때문이다. 그러다보니 사용자도 제대로 구분해서 쓰지 않게 되는 악순환이 일어난다.

게다가 태그 규격마다 필드 이름이 다 다르기 때문에 변환했다가 이상한 필드에 값이 들어가는 경우, 하나의 파일에 여러 종류의 태그 규격이 동시에 기록되어 있어서 프로그램마다 읽고 싶은 걸 읽는 경우, 문자의 인코딩이 깨지는 일까지 일어나면 태그가 만신창이가 된다.

3.2. 주로 쓰이는 태그

제목 : 해당 트랙의 제목.
연도 : 음악이 발매된 연도. 간단해 보이지만 의외로 태그 정리를 힘들게 하는 함정으로, YEAR(연도)와 DATE(날짜)간의 구분이 명확하지 않은 문제가 제일 심각하여, 4자리 연도를 적을지 8자리 연도+월+일을 적을지부터가 문제다. 만약 연월일을 쓴다면 일월년 순서로 할지 연월일 순서로 할지 [2] 등, 무궁무진한 문제의 시발점이다.
또한 음반 정리에 있어서 더더욱 근본적인 문제와도 엮여 있는데, 바로 재발매/ 리마스터/ 리믹스 등의 날짜를 언제로 할지이다. ID3 표준 등에서는 해당 음반의 발매일을 사용하기를 권장하지만, 그렇게 하면 연도 순 정렬이 거의 의미없어지는지게 되어버린다. 원곡이 발표된 연도를 쓰려고 해도 한 앨범 내에서 연도가 여럿이 되는 등 복잡하다. 그래서인지 근본적인 해결책으로 원본 발매년도(ID3v2의 TORI) 같은 필드가 만들어지기도 했지만 결국 플레이어가 지원하지 않으면 쓸 수 없고, 원곡 발매년도를 쓸 것인지 원래 음반 발매년도를 쓸 것인지와 같은 문제가 계속 남는다.

날짜 : 연도 대신 날짜를 기입하는 방식도 있다. Vorbis comment(ogg, flac, opus)의 경우 ISO 8601 방식(YYYY-MM-DD, YYYY-MM, YYYY)으로 날짜를 기록한다.

아티스트 : 해당 노래를 부르고 음악을 연주한 아티스트. 원래대로라면 녹음에 참여한 음악가들 모두를 적는 게 맞으나, 여러 항목을 지원하지 않거나 "참여"의 기준이 모호하거나 하여 앨범아티스트와 같은 값이 되는 경우도 많다.
앨범 아티스트 : 해당 트랙이 수록된 앨범의 주 아티스트. 많은 플레이어에서 "앨범 아티스트와 앨범 이름"을 기준으로 각 노래 트랙들을 하나의 앨범으로 묶는다.[3] 앨범 전면에 이름이 적힌 아티스트를 쓰면 괜찮은 경우가 대부분이지만 "주된" 아티스트가 명확하지 않은 경우가 매우 많다. 컴필레이션 앨범이라면 아예 없어서 비워두거나 Various Artists를 써야만 하고, 두 밴드가 협연했다면 무엇을 넣을지, 작곡가만 같은 여러 클래식 녹음을 컴필레이션 하는 경우라면 무엇을 넣을지 등 고민하게 된다.
앨범 : 해당 트랙이 수록된 앨범(또는 음반)의 이름. 멀쩡한 하나의 앨범을 2CD라는 이유로 CD1, CD2 같은 접미사를 붙여 두 앨범으로 쪼개놓는 경우가 있고, 한 가수가 같은 이름의 앨범을 여러 개 낸다든가 하는 경우도 있어 아주 간단하지는 않다. 같은 이름의 두 컴필레이션 앨범이 있는 경우에는 하나로 합쳐지지 않도록 다른 구분자를 붙이는 수밖에는 없다.
앨범 아트 : 텍스트가 아닌 이미지 데이터 형태로 저장된다. 그러다보니 규격들마다 세부적 구현이 조금씩 다르다. 요즈음 규격은 앨범 아트 뿐만이 아니라 뒷면, 아티스트의 사진, 디스크의 사진 등등 여러 사진을 넣을 수 있게 한 경우가 많다. 물론 이걸 읽어내는 것은 플레이어의 몫. PNG를 지원하지 않는 플레이어들도 있으므로 JPG를 쓰는 것이 더 안전하다.
장르 : 음악의 장르. 애초에 음악을 장르로 나누는 것 자체가 어렵기 때문에 태그를 달려 하면 고민을 거듭할 수밖에 없다. 음악 분류가 잘 되어있는 서비스들에서는 장르도 계층적으로 되어 있고 한 음악이 여러 장르에 속할 수 있도록 하는 경우가 많지만, 태그에서는 보통 한 가지 장르만 지원하기 때문이다. 그나마 요즘의 규격들은 장르를 자유롭게 기입할 수 있지만, 오래된 규격인 ID3v1에서는 00~79의 숫자로 기록해 각각 장르와 일대일 대응이 되어있었다. 표준은 그렇지만 윈앰프가 확장하여 더 높은 숫자들도 쓰인다. 여차하면 죄다 12(=Other)로 기록된다. 장르 문서와 본 문서에 장르 종류가 정리되어 있다.
트랙 번호 : 음반 내에서 해당 트랙의 번호.
가사 : 말 그대로 가사. 보통 음악과 싱크가 안된 가사(unsyncedlyrics)를 넣지만, 여기에 싱크 정보가 기록된 가사를 넣는 일도 있다.
가사 검색을 지원하는 경우라면 검색에 유용하게 쓸 수 있다. 다만 가수 " 태연"을 검색할 때 가사 "태연하게"가 딸려나올 수 있는 등의 문제도 있다.

3.3. 덜 자주 쓰이는 태그

작품 이름 / 악장 이름 / 번호 : 클래식 음악의 경우에 한 곡이 여러 악장으로 이루어져 있으므로, 트랙이 악장마다 나뉘어진 경우에 쓸 수 있다. 그러나 표준 자체도 복잡하며, 미디어 플레이어마다 제각각의 필드를 쓰거나, 아니면 아예 지원을 안하는 경우가 대부분이다. 자신의 플레이어가 지원한다면 써보자.
작곡가 : 클래시컬을 많이 듣는다면 특히 활용하기 좋다. 그러나 작곡가의 이름이 작곡가 필드가 아닌 아티스트 필드에 들어있는 경우도 왕왕 있다.
작사가/편곡자 : 아티스트 필드보다 더 세부적인 내용을 원할 때 쓸 수 있다.
디스크 번호 : 여러 장으로 이루어진 음반일 경우 해당 트랙이 수록된 디스크의 번호.
BPM : 전자음악 등에서 가끔씩 볼 수 있다.
유통사/레이블 : 레이블 별로 정리하는 데 쓰기 좋은 태그.
WWW : 관련 웹사이트를 적는 태그. 디지털 음원을 구매했을 때 해당 사이트가 적혀 있는 경우가 흔하다.
별점 : rating. 많은 플레이어가 별점을 매기는 기능을 지원하지만, 이걸 기록하는 데에는 표준이 없기 때문에 플레이어마다 각각 다른 이름의 태그를 쓰고 있다. ID3v2에서는 표준이 생기긴 했지만 이전까지 자기 방식을 쓰던 플레이어들은 지원하지도 않는 게 현실이다.
iTunes 관련 태그들 : 아이튠즈는 갭리스나 리플레이게인 등을 지원하기 위해 이런저런 태그를 많이 사용한다. 아이튠즈를 쓰지 않는다면 볼 일은 없으나, 아이튠즈로 인코딩한 파일을 받는 경우에는 볼 수 있다.
인코더 관련 태그들 : lame이나 flac 등의 버전, 설정 등에 관련한 정보. 음질에 신경쓰는 사람들에게는 중요한 요소.
원곡 관련 태그들 : 원래 음반, 원곡 발매년도, 원곡 아티스트, 원곡 작사가 등 리믹스/리마스터/리메이크 등에 사용하기 위한 태그들.
이 외에도 수많은 종류의 표준, 비표준 태그들이 있으며, 사용자가 직접 임의의 태그를 만들어낼 수도 있다.

4. 한 태그에 여러 항목 넣기

앨범, 연도 등의 태그는 하나만 들어가는 게 당연하지만, 여러 아티스트가 협업을 했다거나, 두 장르의 특색을 잘 드러낸다거나 하면 한 태그 이름에 여러 값을 넣고 싶어진다. 문제는 여기서도 역시 표준이 없다는 것이다. 흔하게 쓰이는 방법은 다음의 두 가지이다.

4.1. 중복 필드 사용

ARTIST	아이유
ARTIST	슈가

이런 식으로 참여한 아티스트의 수 만큼 개별 아티스트 필드를 만드는 것. 가장 합리적인 방법이지만, 문제는 한 가지 이름의 필드는 하나씩만 지원하는 규격에서는 사용하지 못한다는 것이다.

또한 미디어 플레이어가 있는대로 다 읽어줄 거라는 보장도 없다. 보험성으로 가장 중요한 아티스트를 제일 앞에 있게 뒀는데 미디어 플레이어가 가장 마지막의 것만 읽어냈다(=뒤에 오는 항목이 앞에 오는 항목의 값을 덮어썼다)는 이야기도 있다. 특히 하나의 필드만 지원하는 플레이어의 경우, 태그를 수정하다가 변경된 항목만 바꾸는 게 아니라 태그 영역 전체를 덮어쓰면서 나머지 아티스트의 이름이 모조리 지워진 채로 저장될 가능성이 있다.

4.2. 구분자 사용

ARTIST

아이유; 슈가

또는

ARTIST

아이유/ 슈가

와 같은 형태로 저장하는 것. 모든 규격에서 쓸 수 있고 중복 필드와는 다르게 나머지 대상을 인식하지 못하는 문제도 없지만 역시 /나 ;를 구분자로 보지 않는 미디어 플레이어서는 이름이 "아이유; 슈가"인 아티스트라고 생각할 테니 문제가 된다. 즉 이상적이라면 아이유의 곡 목록과 슈가의 곡 목록 두 가지에서 모두 보여야 하는데, 웬 '아이유; 슈가' 라는 정체불명의 아티스트가 생겨나기 때문에 태그로써의 목적성을 잃는다.

구분자가 ;와 /로 이원화된 것 자체도 큰 문제이다. 윈도우(미디어 플레이어, 탐색기)에서는 ;를 쓰고, 안드로이드(구글뮤직)에서는 /를 쓴다. /로 쓰되 / 뒤에 공백을 넣어 뒤쪽 아티스트 이름이 검색이 되게 적는 것을 추천한다.

휴대기기에서는 위 두 가지 모두 아예 지원하지 않는 경우가 대부분이다.

5. 태그 규격들

5.1. ID3

ID3은(는) 여기로 연결됩니다.

폭스바겐의 소형 전기 자동차에 대한 내용은 폭스바겐 ID.3 문서 참고하십시오.
MP3 파일의 경우 이후의 많은 음악 코덱들과 달리 컨테이너를 사용하지 않고 오디오 데이터가 바로 노출되어 있다. 따라서 태그를 넣으려면 파일 구조에 손을 댈 필요가 있다. 1996년에 ID3v1가 발표되자 커다란 인기를 끌어 사실상 표준이 되었고, 이후로 계속 발전하여 현재 ID3v2.3과 ID3v2.4가 널리 쓰인다.

ID3v1은 음악 파일 끝에 태깅하는 방식이다. 미디어 플레이어를 가리지 않으며 왠만해서는 에러가 나지 않지만, 용량에 한계가 있고 스트리밍 방식에 최적화되어 있지 않다. 또한 유니코드를 지원하지 않기 때문에 언어가 맞지 않으면 문자 깨짐이 발생한다.
ID3v2.3(ISO-8859-1)은 영어 외 라틴어 등 유럽 언어를 인코딩할 수 있는 태그 방식이다. 한글은 지원하지 않는다.
ID3v2.3( ANSI/ MBCS)은 영어 외 다른 언어를 인코딩할 수 있는 태그 방식이다. ID3v2.3(ISO-8859-1)과 호환이 가능하며 한글도 지원하지만, 유니코드가 아닌 시스템 로캘 설정(한글은 CP949)을 사용하기 때문에 언어가 맞지 않으면 문자 깨짐이 발생한다.
ID3v2.3(UTF-16)은 유니코드의 모든 언어를 인코딩할 수 있는 태그 방식이며 호환되는 기기가 비교적 다양한 편이다. 그러나 BOM 처리 방식에 따라 문자 깨짐이 발생할 수 있다.
ID3v2.4( UTF-8)은 UTF-8로 문자를 인코딩하여 문자 깨짐이 발생하지 않지만, 호환성이 가장 낮아서 지원하지 않는 플레이어가 있다.

파일 탐색기에서 태그를 수정할 때 Windows 7은 ID3v2.3으로만 읽고 쓸 수 있으며, 태그를 최초로 작성할 시에는 기본적으로 ID3v2.3(UTF-16)으로 저장한다. Windows 10은 ID3v2.3, v2.4 모두 읽고 쓸 수 있으나, 태그를 최초로 작성할 시에는 기본적으로 ID3v2.3(UTF-16)으로 저장한다. 스마트폰의 경우, 삼성 뮤직은 ID3v2.3(ANSI/MBCS)[4] 및 ID3v2.3(UTF-16)으로 된 태그를 읽을 수 있으며, ID3v2.4로 저장된 태그는 읽지 못한다. LG 기본 뮤직 플레이어[5]는 ID3v2.3 태그를 읽지 못하며 ID3v1 태그만 읽을 수 있다.

6. 컨테이너 오디오 파일

m4a, WMA, 그리고 기타 "미디어 컨테이너명 확장자"를 가진 파일들은 해당 컨테이너가 정의한 메타데이터(=태그) 방식으로 저장된다.

m4a는 MP4 컨테이너에서 정해진 규격으로 메타데이터를 관리한다.
WebM과 mka는 Matroska 컨테이너 규격으로 메타데이터를 관리한다.
WMA역시 WMV 컨테이너 규격에 맞춰 관리된다.
Oga, FLAC은 Ogg 컨테이너 내 정의된 Vorbis comment라는 메타데이터 방식으로 저장된다. 다만 ogg가 flac에 비해 잘 쓰이지 않고, flac 자체로 태그(앨범아트)를 정의해서 쓰는 바람에 태깅 방식에 교통정리가 필요하다는 문제가 있다. 컨테이너 자체에 정보를 저장하는 공간이 있어서 막상 "태그"라고 부르기 모호한 점이 있긴 한데, 따로 " 메타데이터"로 부르기도 한다. 이 "메타데이터" 안에 검색용 키워드( 태그)를 기록하는 "태그 항목"이 따로 존재하기도 한다.

7. 기타

2종 이상의 태그를 동시에 저장할 수도 있다. 다양한 기기에 지원이 되는 장점이 있으나, 용량이 좀 늘어나는 단점도 있다. 텍스트가 중복되어 기록되는 것은 큰 문제는 안 되지만, 앨범아트가 태그방식마다 여러번 기록되면 용량이 급격하게 상승할 수 있다.[6] 보유곡이 2~3000곡 이상이라면 여러 태그로 저장할 경우 티끌모아 태산이란 느낌처럼 용량 증가가 눈에 띈다. mp3 재생 프로그램이라고 모든 태그를 읽는 것은 아니니, 자신이 주로 쓰는 mp3 플레이어에서 지원하는 태그방식만 두고 나머지는 삭제하는 것이 좋다. 과거에는 기기 제조사마다 달랐으나, 현재는 스마트폰만 바라보면 되니(구글 아니면 애플) 신경쓸 것은 많이 줄어들었다.

난잡한 태그를 보다 보면 태그를 깔끔하게 정리하고픈 충동이 들 게 마련인데, 웬만하면 건드리지 말 것. 사람이 할 짓이 못 된다. 막상 시작하게 되면 아티스트명을 한글로 적을지 영어로 적을지부터 장르를 어떻게 정리할지 등 너무나도 많은 경우의 수가 존재하기 때문에 머리가 터지기 일쑤이며, 엎친데 덮쳐서 한 번 건드린 이상 가지고 있는 모든 음악의 태그가 완벽해질 때까지 멈추기가 어렵다. 애초에 멜론, 지니뮤직, VIBE, 벅스 등의 음원 사이트도 각 사이트마다 같은 음원의 태그 형식이 제각각이며, 같은 사이트 내에서도 앨범, 음원마다 태그 형식이 제각각이다. 음원 유통사나 기획사 측에서 요구하는 형식과 음원 사이트 측에서 자체적으로 규정하는 형식이 다르다 보니 충돌이 발생하는 경우가 대부분이고, 어떤 경우는 어느 한 쪽의 의견이 일방적으로 수용되기도 하고, 어떤 건 또 절충안으로 가기도 하고 하다 보니 결국 혼파망을 피할 수 없다. 즉, 애초에 이런 거 똑바로 맞춰야 할 곳들마저도 손 놓아버렸다는 뜻. 이런 상황에서 새로 들어오는 음원도 출처는 다 제각각일텐데 그 때마다 이 짓을 하자니... 어휴...

차라리 태그를 모두 정리하고 말겠다는 생각을 포기하고 아티스트명, 제목, 파일명 등 자신이 주로 쓰는 앱에서 활용(정렬, 검색)하는 태그만 통일하거나, 자신이 주로 검색할 단어만 형식을 통일시켜두면 시간 낭비를 조금 덜 수 있다. 아이튠즈 매치와 모종의 유틸을 이용하면 쉽게 정리된다 카더라가 있었는데 업데이트의 결과로 그 축복도 이제는 옛날 얘기다. 만약 태그 정리 목적이 "플레이리스트"생성에 있다면, 태그정리보다 "m3u(m3u8), pls(pla), asx"같은 플레이리스트 파일을 만들고 앱에 인식시키는 방법을 찾는 것이 훨씬 빠르고 편리하다.

[1] 가령 "아이유→아이유(IU)→아이유 (IU)", "수지(Miss A) → 수지(SUZY)", " 우리동네 음악대장 → 하현우"같은 케이스. [2] 20201120 대 20112020, 또는 11202020, ... [3] 즉 아티스트가 다르더라도 앨범아티스트와 앨범 이름이 같으면 같은 앨범에 속하는 것으로 처리한다. [4] 원래는 ID3v2.3(ISO-8859-1)으로 인식했으나, 이후 업데이트를 통해 인코딩을 알아서 인식하게 되었다. [5] 2020년 10월 4일 V20 기준 [6] 1000 * 1000 이상의 커다란 크기에 파일 형식을 PNG로 할 경우 앨범아트 용량만 1~2MB는 기본으로 나오며 심하면 5MB 이상도 나온다. 앨범을 메타데이터(텍스트) 영역에 Base64로 넣을지, 컨테이너에 바이너리로 넣을지 둘다 넣을지 편집프로그램이 헷갈려 한다면 용량이 배로 늘어날 수도 있다.