MusicBrainz tags not displaying in old Sony Player

Hi all,
I’ve been using Windows Groove to manually add tags for a while now.
My PC bricked and so I’m temporarily using a laptop with Ubuntu Linux.
I found MusicBrainz Picard as a Groove replacement and was super excited because it was automatic, intuitive, and worked well… until I transferred the files.

I am using a Sony Walkman NWZ-E436F with the latest Firmware.
When I transfer album folders that I’ve tagged with Picard to it, the Album-Art and Year show up, but the songs are not recognized as an album, and are missing Artist and Genre.

I’ve found a couple forum posts describing the limited ability of old players reading new ID3 formats, like this one, and tried downgrading my ID3 version in Picard Options, then re-applying the tags. The suggested route, ID3v2.3 using ISO-8859-1 and excluding ID3v1 tags, does not work.

There are 4 main things I’ve been trying:

  1. Different combinations of ID3 version settings to see if I can find the “perfect fit” for my Walkman.
  2. Verifying that Picard is actually using my preferred ID3 version for the tags. I’ve checked with PuddleTag here-and-there but nothing seriously. It has sometimes identified my songs as ID3v2.4 when my preferences have been set to ID3v2.3.
  3. Using EarTag/puddletag to delete all the extra MusicBrainz info off the tracks. There was a forum post somewhere (for a different player) that said MusicBrainz tags may be overloading the ID3v2.3 tags or just confusing the player itself. This has not worked.
  4. Investigating the possibility that it is just Ubuntu/Linux messing up the file transfer. (Updt: relevant post)

I’m hoping someone can help me narrow down the problem, or just tell me straight-up, “musicBrainz does not work for a mediaPlayer that old / with that firmware”

This has all been a really confusing mess but I super-duper want to keep using Picard since it works so well otherwise.

Update:
The manual for my device has a “supported formats” list on page 118, but it isn’t much help (only mentions mp3/wma/aac).
Pages 9 and 27 of the manual heavily imply Window Media Player (and maybe WindowsOS?) are the only reliable way to transfer data. Maybe this is merely a linux issue and does not involve MusicBrainz. Will do some tests soon.

Update: (SOLVED!)
The issue arises from a bug between the Sony firmware and Linux. We think it occurs when the Walkman is updating its internal library after the file transfer.
In the end, my NWZ-E436F Walkman can read MusicBrainz’s tags perfectly fine as long as they’re transferred from a Windows computer.

Seeing as this isn’t a Linux forum, and everything on the MusicBrainz/Picard side is working correctly, that’s probably where this thread will end. If you’re looking for a way to fix the Linux bug, try the Debian forum post mentioned in point #4.

FYI: On Windows, I still used ID3v2.3, but ISO/ID3v1 settings don’t seem to matter. Haven’t tested ID3v2.4, though.

2 Likes

When you save an album or track in Picard, it stores several special ids (MBIDs) for Album Artists, (track) Artists, Release Groups, Release and Recording as tags in the files.

Then when you reload the same tracks into Picard at a later time, these are used to automatically match the tracks to a release and download the Musicbrainz data.

However, the first time you load the files into Picard it doesn’t have these MBIDs and so the best it can do is to use the directory structure to group files into “clusters” and use existing tags and details from the full file path to try to guess missing tags.

When you click Lookup, it uses the tags it has to try to identify the best matching release from MusicBrainz, but this is a guess and it might get it wrong, and in some cases it can’t make any reasonable guess.

So on the first load, it is the users responsibility to determine whether the release is correct or not, and if not to identify what the correct release is.

The Picard documentation web site has a whole section devoted to explaining workflows like this - please take a look if you are unsure.

Hi, thanks for the quick response!
I think I should clarify,
The tags that MusicBrainz Picard has applied to my music are 100% correct. However, when I transfer that music to my old Sony Walkman, some tags are not being displayed (album, artist, and genre are displayed as unknown).

What workflow are you suggesting I use the Picard documentation to research? Point 2 seems the most likely, but that would really just be a bug, no?

You need to look up what tagging formats the Sony Walkman supports. For mp3 files the options are ID3v1, ID3v2.3 and ID3v2.4. You can set the correct format in Options…/Options.

You need to work out what Groove was doing to the files that your old player liked.

Find some of those files, and maybe chuck them on WeTransfer so I can have a look. Or other file sharing.

I don’t know how to check in Linux, but we need to work out what version of tagging level they are using. The “ID3v1, ID3v2.3 and ID3v2.4” mentioned above.

I am guessing you are probably ID3v2.3? It may also be that specific tags are being read by the Sony player that Picard is not (yet) setting for you.

But it is also highly possible the Microsoft Groove app was up to other oddities.

I’ll see if I can find a spec for it. I always uninstalled it from Windows machines…

I would have been surprised it is wasn’t using ID3v2.4 as Win10 added support in the file manager for reading those level of tags.

Both this and this informally claim that their old walkman only reads ID3v2.3 with ISO-8859-1. I cannot find an official source to confirm this.

Assuming this is the tagging format that my Walkman supports, I have set it up in Options to be my default. After tagging my music with this format on Picard, I transfer it to my Walkman, which then displays the Album, Artist, and Year as Unknown.

Is it possible that my Walkman is confused by the extra MusicBrainz tags that are added? or do most DAP ignore extra tags that they can’t understand?

Generally players just ignore what they don’t understand.

Going backwards and setting to ID3v2.3 makes most sense.

Also be aware than many old players will expect the date to be a four digit year and not a full yyyy-mm-dd date.

I’ll see if I can find a PC to whack Groove on to and see exactly how it tags.

Also how old is your Sony Walkman? Note that some of those articles you linked are 2011…

Dumbest and oldest option in Picard:

Some players may be so old they even need that ID3v1 ticked.

Hello!
I see your first reply and I’ll get back to that ASAP.
Regarding this, though:

I noticed the yyyy-mm-dd discrepancy too and fixed it, doesn’t seem to be the problem.
I have the NWZ-E436F, released in 2008. Old…
I have tried the settings pictured, and confirmed that Picard applied them correctly using puddleTag. Unfortunately the issue persists. I have also tried leaving only the ID3v1 tag (again with puddleTag) on my music. Re-transferred that to the walkman and does not work either.
I think this mostly excludes using (Edt: older) ID3 version format as the root of the problem, but I’m going to try to open those Groove files and see…

This may be a thing. The oldest Sony players made you use a specific Sony Windows app to transfer music onto them. Finally they gave up on that and went to MP3 files.

Sony could easily be using a specific file transfer method from Windows Media player as you have two copyright loving companies there.

A simple test. Plug Sony into the computer, attempt to MOVE music off of the device. Delete it from the Walkman. Try to play it on the computer. Then drag that music back onto the Walkman without changing the tags. Does it still play on the Walkman?

If that above manoeuvre works then you do’nt have file transfer issues.

Modern devices tend to just work like USB flash drives.

confirmed that the working Microsoft Groove files are formatted in ID3v2.3

Okay. That makes sense for the Sony.

So really the Picard ID3v2.3 should do the same. I’d try the dumb ASCII (ISO-8859-1) option but really UTF-16 should work too.

Do ANY tags show up? It could be that the Sony is reading a different tag to the standard “Artist” tag. In your post you say the album-art and Year appears? but nothing else?

I would try NOT embedding artwork. Remove the artwork and do a test. Modern art is huge and could be upsetting the memory in the Sony.

(After testing with no art, you could set Picard to use 250px or 500px art. Can Puddletag tell you the size of artwork embedded by Groove?)

Tried this out, must be a file transfer issue.

Took an album that worked (edited on Groove & transferred from Microsoft Windows PC) and moved it to my Linux/Ubuntu PC. I could read the tags/listen to music fine on the PC. Moved it back to Walkman and open it up. It’s now missing Album, Artist, Genre, and Title… just like my original problematic Album/music. This is almost identical to the forum post I mentioned in Point #4.

I think next steps from here are to either:
Switch to Windows PC when transferring to this specific Walkman
or Modifying Root Permissions of my Ubuntu/Linux PC like the forum post suggest

I think I’ll try to get my hands on a Windows PC and try Groove/Picard/etc on it. I’ll come back with a (hopefully) final update when I do.

1 Like

See my recent reply,

regardless though, I did coincidentally try these (separated art and reduced size art) already and neither changed much. Good to see we were on the same wave-length here though.

This is quite a bizarre thing if that happened. I don’t follow the logic as to why a file system should change the files to a state that the tags are corrupted. Copying files should be copying files. (Will read the forum post in a bit) Okay… now it makes sense… Not corrupted, just not updating the database on the device.

But I can also see how Sony may well have installed something into the MS OS to make their file transfers “special”. It may just be the Sony is wedded to MS systems only due to their love of DRM and Copyright.

I wonder what would happen on an Apple Mac. Guess it would behave same as other *nix systems.

Been down this road before. In a drawer behind me is an ancient Sony MP3 player. Probably before 2008. In parts though so not useable to test.

I’ve seen a whole history of “special” treatment from Sony over the years.

1 Like

Okay - now I read the forum post that makes sense. MTP may just be slightly buggy on the Sony. OR the version in *nix that talks to the Sony device.

How often do you re-load the Sony Walkman? If I was you I’d just stick my new music on a flash drive, then find a mate’s or library or workplace Windows PC to do the transfer. I can certainly see how a bug like this in Sony to Linux transfers gets missed.

I guess simple things like rebooting the Sony devices does not make it read the tags?

I have a similar oddity on my ancient Android phone. I still have an old Android, and that does not always correctly read the images. So the database of images attached to the music just gets knackered. And I’ve never found a simple way of kicking the phone to rebuild that database.

I think there’s a way of soft-reseting this model so I might try that out too.
It could be a temporary bug.

This is some weird shit happening here.

I couple of file transfer things that come to mind, though it is difficult to see how these could kick in:

  • FTP - there is an ascii mode and a binary mode. Perhaps some other ways of transferring files do the same.
  • Endian-ism - some processors are big-endian, some little-endian (to do with byte ordering) - but I would imagine it likely that both Windows and Linux are Intel and so same-endian.
  • Mime - downloads are often done using Mime, and different mime types could impact things somehow.

But I really don’t think that any of these have been used in the chain of actions described above.

My understanding: The fault here is based around the Sony player not actually knowing to read the tags. It does not update its internal database.

This is nothing to do with the quality of the actual tags. Or corrupted files.

Old players like this don’t read the tags on the fly when they look at the files. Processors too slow. Instead when you add file they read those tags into a database at that point only.

Action should be - add music, read tags to database.

Action Scroll music - only show what library knows. You are not walking the files. Just the database.

Play music - use the database to show you what that music is.

The fault is that the database is not kicked into updating correctly. Files drop in, it sees files, but database can’t tell you what they are. The “MTP” transfer mode should be what triggers the database update. For some reason this does not update.

Probably due to Sony in 2008 only really testing on Windows. So their buggy code worked with Windows buggy code.

Swap to linux and now the libraries have a clashing bug. Maybe Linux doesn’t tell the Sony to update its library. Or the Sony is too dumb to notice new files appear.

So music files are correctly on the device, just device does not know to update its internal library.

The device only reads tags ONCE. The one time they are copied to the device. This is the only chance to update the database. And if not told to update correctly, then the database ends up out of date.

This is why I suggested “take some files off, and put them back on again” test. That showed files that were once read as fine (when added via Windoze) are now reading as “bad” (when added via Linux). Files didn’t change, just the device knowing to read them.

3 Likes

Hey there
This is a little above my pay-grade in terms of computer tech/software, but it seems like a pretty sounds explanation as to why Files don’t “transfer correctly” from Linux to my old Walkman. One thing to note, after my Walkman is removed from connection to PC, it enters a Creating Library loading screen. I assume this is the “update [to] its internal library” that you mentioned. If anyone wants to investigate this issue further in the future, also important to note that this loading screen appears after connection to both Windows and Linux. So… the Walkman at least thinks its updating its library, even if its doing it wrong.

1 Like