I am putting English names in front of my Japanese and Chinese artists so that they can be sorted in Alphabetical order. 95% of my albumartistsort tags are working as intended, but there are quite a few artists despite having the albumartistsort in the tag, does not sort accordingly and ended up at the very bottom of the album artist page.
Attaching screenshots as an example. While both Sheena Ringo and Tokyo Jihen both has the similar tagging, Tokyo Jihen was sorted properly to the alphabetical order but Sheena Ringo did not.
Have already tried clearing cache/ all the tags and resync. Same issue prevails.
Belief have nothing to do here I know that matters more
Everything is merged an artist and an album artist or a composer is still an artist with one sort value. If they are not consistent you can’t know the one that will be used as it depend on scan order.
You can provide a logs containing a full sync after a clear tag cache so I find out what you missed, but then will you pay for the time done doing that
I did keep Tokyo Jihen’s folder in Sheena Ringo’s folder. It was intended and not a mistake.
And Tokyo jihen despite having different artistsort, composersort than albumartistsort, it is working properly.
Also I am not saying it’s the app’s fault. Just trying to figure things out being constructive, no need to be so aggressive…
Fyi if you did not know, sheena ringo and tokyo jihen are two different things, even though I kept them in the same folder, it is just because tokyo jihen’s vocal being sheena ringo. And that what you have quoted is tokyo jihen, which is working correctly.
Forgot to mention, I was “fixing” the tag of another artist since I only have one song on that artist, and it would not take as long to sync as to if I am changing the big chunk of files from sheena ringo.
I really like your app Sir Tolriq, but if the issue persists I would have to change all the albumartistsort back to album artist which will not match with any of the database like musicbrainz X_X
I did change all these “sort names”, cleared tag, and sync again. I am only using this single file to experiment so I don’t have to sync all the files to my DAP every time.
I apologize for wasting your precious time but I think we have some communication problems here…
Tried using foobar to remove all paddings, retagging using musicbee/ mp3tag. All no avail…
Guess I will just move all the sort name back to album artist and forget about matching the database then. Thx for the help anyways.
albumartistsort: Split multivalue tag AND Associated column = albumartists
artists: Split multivalue tag
artistsort: Split multivalue tag AND Associated column = artists
composer: Split multivalue tag
composersort: Split multivalue tag AND Associated column = composer
Click OK
Library > SQLite console: paste and Execute the following code
with distinctArtists as ( select artists, artistsort from mediaLibrary union select albumartists, albumartistsort from mediaLibrary union select composer, composersort from mediaLibrary ) select a.artists, a.artistsort from distinctArtists a inner join ( select artists from distinctArtists group by artists having count(distinct artistsort) > 1 ) b on (a.artists = b.artists);
To keep things manageable this ignores case (“David Bowie” vs “David bowie”) but should be enough to highlight the bigger sort problems (the ones causing them to appear out of order).
Let me know if you want to dive into case related differences.
Time is precious for everyone, one day you’ll understand that it’s the only thing you can’t purchase, and that listening to those who know instead of arguing is a better use of time.
I don’t mean to waste YOUR precious time. Time is precious for everyone and this is a “Support” thread which is supposed to be time consuming to solve problems.
As for the log you have gotten, it is a song from a different album that is working absolutely fine, and sorted properly under another artist, “Aimer” 's Album Artist.
Let’s forget about those files. Here is the file I am experimenting with:
MediaInfo report of “01. Keep Your Fire Burning.m4a” :
General
Complete name : 01. Keep Your Fire Burning.m4a
Format : MPEG-4
Format profile : Apple audio with iTunes info
Codec ID : M4A (M4A /mp42/isom)
File size : 71.0 MiB
Duration : 3 min 22 s
Overall bit rate : 2 934 kb/s
Title : Keep Your Fire Burning
Album : Keep Your Fire Burning
Album/Sorted by : Keep Your Fire Burning
Album/Performer : 阿部真央
Album/Performer/Sort : Abe Mao 阿部真央
Part/Position : 1
Part/Total : 1
Track name/Position : 1
Track name/Total : 1
Performer : 阿部真央
Performer/Sorted by : Abe Mao 阿部真央
Composer : 阿部真央
Composer/Sorted by : Abe Mao 阿部真央
Publisher : KAGAYAKI RECORDS
Label : KAGAYAKI RECORDS
Genre : J-Pop
Recorded date : 2024-01-09
Encoded date : 2024-05-16 02:26:02 UTC
Tagged date : 2024-05-16 02:26:02 UTC
ISRC : JPPC02312672
Copyright : ℗ 2024 PONY CANYON/IRORI Records / KAGAYAKI RECORDS
Cover : Yes
Cover type : Cover
Rating : None
PlayListID : 1720743858
UPC : 4524135161864
Title/Sort : Keep Your Fire Burning
replaygain_track_peak : 0.991176
replaygain_track_gain : -7.66 dB
replaygain_album_peak : 0.991176
replaygain_album_gain : -7.66 dB
RELEASETIME : 2024-01-09
DISPLAY ARTIST : 阿部真央
Audio
ID : 1
Format : ALAC
Codec ID : alac
Codec ID/Info : Apple Lossless Audio Codec
Duration : 3 min 22 s
Nominal bit rate : 4 608 kb/s
Channel(s) : 2 channels
Sampling rate : 96.0 kHz
Bit depth : 24 bits
Title : Core Media Audio
Encoded date : 2024-05-16 02:26:02 UTC
Tagged date : 2024-07-15 20:07:19 UTC
Image
Type : Cover
Format : JPEG
Muxing mode : moov-meta-covr
Width : 2 400 pixels
Height : 2 400 pixels
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Compression mode : Lossy
Stream size : 795 KiB (1%) / 795 KiB (1%)
Microsoft Windows [Version 10.0.26100.8246]
(c) Microsoft Corporation. All rights reserved.
D:\Whitelist\Abe Mao 阿部真央\Keep Your Fire Burning - Single>chcp 65001
Active code page: 65001