Embedded MP3 album art not working for MTP-transferred files

[cpurick]

I found the protocol didn't matter. Either way, the J3 shows folder images fine, but it's real hit-and-miss with embedded images.

Someone was saying they had good luck relying entirely on embedded images. I'd like to know more about the software he's using, and what kind of tags it creates.

[CrowdAds]

[dfkt]

There is absolutely no issue with embedded MP3 album art in MSC mode, it works 100% for me, all the time. If you make sure the embedded JPEGs are baseline profile, not progressive, and if you use a decent app like Tag&Rename to embed, it will work. I'm using ID3v2.3 tags only, no ID3v1, and I'm only using whole track numbers with leading zeroes (01, 02, etc), not fractions (1/10, 2/10, etc).

[cpurick]

Originally Posted by dfkt

There is absolutely no issue with embedded MP3 album art in MSC mode, it works 100% for me, all the time. If you make sure the embedded JPEGs are baseline profile, not progressive, and if you use a decent app like Tag&Rename to embed, it will work. I'm using ID3v2.3 tags only, no ID3v1, and I'm only using whole track numbers with leading zeroes (01, 02, etc), not fractions (1/10, 2/10, etc).

I think there's a difference between "you're not having issues" and "there is absolutely no issue."

Best I can tell, the only difference between you and me is that my track numbers don't have leading zeros. MP3Tag identifies all my tags as ID3v2.3. Many (but nowhere near all) display art in the player, but none have the zero.

Are you saying that if you switched to MTP the art would stop working? I see no difference when I do it -- even after deleting and retransmitting all the files on the player.

How do you actually move the files to the J3? Are you using Windows Explorer, or are you going through a library tool?

And you are saying there are no .jpg files in the album folders on your device?

[DSperber]

Originally Posted by cpurick

Best I can tell, the only difference between you and me is that my track numbers don't have leading zeros.

Just to clarify the problem: when a file containing imbedded art is copied to the J3 while the J3 is in MTP mode, that art does not show up on the Player when playing that track. Instead, only the blank white disc appears.

And even when the player is reverted back to MSC mode, the same blank white disc STILL appears... again ignoring the imbedded art, on this file which was originally copied to the J3 while it was in MTP mode. I believe the "cache" that identifies the presence/absence of album art occurs on the first re-boot after the file got copied, and since the J3 is thus still in MTP mode at this re-boot the bug in the firmware must be that it fails to analyze files for imbedded art when the re-boot takes place while the J3 is in MTP mode. And once the "cache" is created defining the so-called absence of imbedded art (which, of course, is NOT the case... but it's just not being looked for) the file is never examined again.

So the only way to get the art to appear correctly is to delete the file copied while in MTP mode, and re-copy the file while in MSC mode (changing nothing else at all in the file or ID3 tag), remove the J3 and re-boot (with J3 still in MSC mode, such that analysis for imbedded art DOES occur and gets cached properly), and now the imbedded album art appears in Player perfectly... whether the J3 is left in MSC mode or even if it is reverted to MTP mode.

The key is the state of the J3 when the file containing imbedded art got originally copied to the J3 (and thus the mode of the J3 during that crucial first re-boot after the copy is finished). If the J3 was in MTP mode at first re-boot time then that imbedded art never appears (in MTP or MSC mode). If the J3 was in MSC mode at first re-boot time then that art always appears (in MTP or MSC mode).

MP3Tag identifies all my tags as ID3v2.3. Many (but nowhere near all) display art in the player, but none have the zero.

My ID3 tags contain both ID3v1 and ID3v2.3, and also contain fractional tracks with no unnecessary leading zeroes (e.g. 1/12, 2/12,... 10/12, etc.).

And I confirm the problem. If art is imbedded into the ID3v2.3 tag and the file is copied to the J3 while it's in MTP mode, when the J3 is disconnected and re-booted that imbedded art will never appear in Player.

Are you saying that if you switched to MTP the art would stop working?

Yes. If the J3 is in MTP mode when the copy is performed and is also the mode at first re-boot, imbedded art in that file will NOT appear in Player.

I'm personally of the opinion it is a firmware bug that simply fails to analyze files for imbedded art while in MTP mode, and the file is thus marked (in cache) as not having art although it really does. And thus it will now never have its art displayed.

How do you actually move the files to the J3? Are you using Windows Explorer, or are you going through a library tool?

I personally have no file manager program that recognizes MTP mode (i.e. "internal storage" and "external storage" of the "Cowon J3" removable device). All my assorted programs only support MSC mode, where Windows assigns actual drive letters to the two storage classes.

Thus for me Windows Explorer is the ONLY method I know of which can copy files from PC hard drive to the J3 when the J3 is in MTP mode.

And you are saying there are no .jpg files in the album folders on your device?

I have a mix, with cover.jpg files in my album folders being the true 100% way I handle album art for tracks in that album folder.

I only performed this "MTP-transfer of a file containing imbedded art" experiment on one single file, to determine whether or not the reported problem occurred for me as well. And it does.

[meetooman]

Thank you DSperber for the summary on this issue. As someone finally file the bug to Cowon?

[chartrex]

I have encountered this exact problem and indeed it took me a while to realize exactly why I wasn't getting embedded art to show up on newly transferred music. I thought it was a problem with playlists originally, but hey, once back in MSC mode, everything works fine again... glad to see it's not something unique to my equipment.

[DSperber]

Originally Posted by meetooman

Has someone finally filed the bug to Cowon?

Yes, I submitted this problem report to them last week. Still no answer back.

Now maybe I have some false hope here, but looking at the release dates for the past few firmware releases, it does appear that they've been rolled out kind of on a monthly schedule. And this would mean whatever is the next version should be released imminently.

But it might be a bit late, as they mentioned in a reply to one of my other tickets regarding M3U playlist issues that they would be addressed in the "next" firmware release. Since this whole subject is a tough one, with some serious problems that need to be overcome (e.g. handling M3U playlists that reference music files on both internal and external storage) I wouldn't be surprised if this takes more time than usual.

Anyway, I wouldn't expect this MTP-related problem we're discussing to be fixed in this upcoming release. But at least they know about it (assuming they read my ticket).

[lestatar]

This sounds soooo stupid, but in glancing through all these posts, I didn't notice any mention of this, so...

Have any of your tried setting some test files with embedded art to read-only and then using MTP to transfer the file? Perhaps in conjunction with Winamp [though I know dfkt uses Winamp and I am sure he already tried that].

I know, sooo basic and stupid and probably completely useless and irrelevant, but I am dying to know the results if someone could try it.

I am baffled as well as this whole issue does not seem to make sense to me.

[dfkt]

As I said, the album art is still there in the files when I transfer them back to the computer. The files don't get altered. It's just not displayed on the J3.

[lestatar]

dammm, sooo weird

[DSperber]

Originally Posted by lestatar

dammm, sooo weird

Hey... bugs are bugs.

2.21 had the problem with Matrix Browser "losing" album art. Something they'd done in 2.21 had simply caused the boot-time processing to overlook the step of "[check albums]", which apparently is when the analysis/sync of album art (for new/changed files and folders) to occur and the \System\MusicDB contents to be updated with the AB_nnn.jpg mini-images used by Matrix Browser.

The art was still there, in the folders and in the files, but it just was not being looked for. Nor was the "sync" step (deleting obsolete and creating new) involving AB_nnn.jpg mini-images performed.

So you ended up with old, obsolete, out-of-date and missing tiles in 2x5 Matrix Browser.

Once they reinstated that crucial "[Check Albums]" step at boot time with the 2.22 fix, everything started working properly again.

My guess is that this is something similar. It's my guess that the particular sub-function which analyzes files for imbedded art is simply overlooked (obviously not by intentional design, but just because of this bug) when the J3 is booted while in MTP mode. And once the cache resulting from this analysis shows "no album art" then you will never ever get to see it (unless you delete the file, revert to MSC mode, re-copy, and re-boot while in MSC mode).

The file with the imbedded art is not touched or modified while in MTP mode. It's just not looked inside of at boot time for imbedded art. And after that, it's like there simply was no imbedded art at all... which is obviously not true.

[DSperber]

Just an update to this obvious Cowon bug...

This thread over on the iaudiophile.net forum describes a second symptom which seems tied to transferring files while in MTP mode... specifically to external storage of the J3. The problem does NOT occur when transferring the identical files to internal storage of the J3.

The issue concerns OGG files, and the fact that the entire tag (Vorbis Comments, I believe) is not examined at next boot by the J3... if (a) the file is transferred while in MTP mode, and (b) the file is transferred to external storage of the J3.

As a consequence of this "failure to analyze", none of the tag fields for the file are analyzed and placed in the database at next-boot following the MTP transfer, and the file is thus not seen when using "Music" to browse by tag fields. The file can be reached using "Browser" and navigating through [J3 Ext], but none of the Vorbis Comments tag fields show up in the "Music" database.

In contrast, if the very same OGG file is copied to internal storage of the J3 while still in MTP mode, the tag fields ARE analyzed at next-boot and thus the music file IS reachable using "Music" to browse tag fields.

And of course, if the J3 is in MSC mode then there's no problem transferring the OGG file to either internal or external storage of the J3. The tag fields are properly analyzed in either case, due to MSC connection.


Sounds like a cousin of the "imbedded art in tags not detected at next boot if file transfer was in MTP mode" bug originally reported by this thread.

Again, seems directly tied to MTP file transfers.

[SEG]

I just want to note that I experienced a similar issue on my X7 (firmware 2.07 and 2.08). I use Napster To Go. The 'rented' music files are .wma with DRM and embedded art. MTP mode is required when transferring files from Napster to the X7. In all cases, the album art does not show on the X7.

However, the embedded album art of the Napster music files does show up on my S9 (firmware 2.53)--again MTP mode required for file transfer.

[DSperber]

Originally Posted by SEG

I just want to note that I experienced a similar issue on my X7 (firmware 2.07 and 2.08). I use Napster To Go. The 'rented' music files are .wma with DRM and embedded art. MTP mode is required when transferring files from Napster to the X7. In all cases, the album art does not show on the X7.

Strange.

WMA tags aren't supposed to be supported by the J3:

Meta Tag: ID3 V1, ID3 V2.2/V2.3/V2.4, Vorbis Comment, and now also APE (with recent firmware upgrade)

I don't have any WMA files, so I can't confirm one way or the other, even if the J3 was connected in MSC mode.

But I believe the research revealed it wasn't that the imbedded art had gotten deleted due to the MTP-mode transfer. In fact, when the files were copied back to the PC, the art was still there.

The problem apparently was that the tag/art/cache analysis that occurs on that first boot after tranferring new files did not occur correctly when the J3 was in MTP mode. The art is definitely present, it's just not being looked for and once the file gets "cached" claiming there's no art, then the art will just never appear.


It occurs to me that if MTP is only required when transferring files, that if you reboot the J3 right after the transfer the imbedded art will not be analyzed. But if you then (a) change the J3 to MSC, (b) connect it to the PC and delete the \System\MusicDB folder contents, (c) safely remove hardware, (d) disconnect from the PC, (e) re-boot while now in MSC mode, that all of the imbedded art which IS really present should be re-discovered and cached properly.

Now you can leave the J3 in MSC mode until you again need to transfer new files from the PC in MTP mode, and you should have all your art... even from the files which you previously transferred while in MTP mode.

Or, you can probably go to MTP mode immediately if you want, and it should still work. The first-boot problem while in MTP mode has been overcome, and all art has been analyzed and cached because that crucial first boot was while still in MSC mode. You should now see that art going forward, no matter whether you're in MTP or MSC mode... since \System\MusicDB is built properly.


Again, I'm still uncertain as to whether imbedded art in WMA tags are supposed to be supported at all.

But this method I've described above, to trigger a first-boot in MSC mode with nothing yet in \System\MusicDB... seems like it should work for tags of other supported file formats (i.e. MP3 and FLAC and APE), to overcome the known problem with imbedded art following MTP transfers.

Somebody could try this, to confirm.

[SEG]

Update.

At first, I was using the Napster software to transfer Napster To Go music files (DRM, WMA) directly from Napster to the X7 (firmware 2.08). When I did this, the album art did not display on the X7.

Then, I tried using the Napster software to transfer Napster music files that were already downloaded to my computer to the X7. In this case, the album art displayed correctly on the X7.

I have no idea why the latter method works and the former does not.

UPDATE: DSperber is probably correct about imbedded art in WMA. I am not finding a ready and definitive answer online, but I now believe that when Napster To Go tracks are transferred to a portable player the album art is stored in files with the .alb file name extension. I'm apologize for any misinformation about embedded album art in WMA files. Still, I don know why the S9 displays the album art either way the files were transferred, whereas the X7 is more picky.

Regarding DSperber's idea to remove the contents of the \System\MusicDB and then rebot, I don't have a J3, so I can't try it. My X7 does not have a \System\MusicDB folder (it does have a \System\Video DB folder).