Finder / iTunes don't display artwork in most cases due to regression from #200

[ksperling]

It looks like Finder / iTunes don't like an empty APIC description string when it's encoded in UTF-16. A non-empty string or encoding with Latin 1 seems to work.

Having the API do exactly the expected thing as per #200 is obviously nice, but I don't think it's justified when it breaks compatibility. Maybe a compromise would be to enable the strict behaviour for 2.4 tags and leave the compatibility logic in place when writing v2.3.

[nicfit]

It looks like Finder / iTunes don't like an empty APIC description string when it's encoded in UTF-16. A non-empty string or encoding with Latin 1 seems to work.

You can "fix" your tags to satisfy itunes, no? Set a non-empty description with whatever encoding makes itunes happy.

[ksperling]

Yes, that's what I've done now, after an afternoon of debugging, looking at hex dumps and trying different things. I just doubt the average user of a tool like eyeD3 wants to (or should have to) go to that sort of effort.

[nicfit]

What, exactly, should eyeD3 do here? Following the ID3 spec as a goal.

Having the API do exactly the expected thing as per #200 is obviously nice, but I don't think it's justified when it breaks compatibility.

Doing the expected thing > Finder/iTunes, IMO

[ksperling]

Of course that expectation only exists at the API level. I’m actually concerned with the command line tool. On the command line I didn’t request any particular encoding of the tags, I just expected to add an image and have it work with commonly used software.

…

On Thu, 17 Oct 2019 at 09:54, nicfit ***@***.***> wrote: What, exactly, should eyeD3 do here? Following the ID3 spec as a goal. Having the API do exactly the expected thing as per #200 <#200> is obviously nice, but I don't think it's justified when it breaks compatibility. Doing the expected thing > Finder/iTunes, IMO — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#343?email_source=notifications&email_token=AAGB6LSYTMQC6ZN4DQDIAHTQO55OJA5CNFSM4I62AD3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBN42TY#issuecomment-542887247>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGB6LTABMHELQXMQ664YC3QO55OJANCNFSM4I62AD3A> .

[will-hedges]

@ksperling I am trying to do this with iTunes as well as Groove. What args do you have to specify to 'play nice' with the artwork? I'm new to file handling with python so please forgive me if this is a dumb question

# find the cover artwork, if present
for f in os.listdir():
    mo = art_re.match(f)
    if mo:
        art = f
        art_ext = f'image/{mo.group(1)}'
        if art_ext == 'image/jpg':
            art_ext = 'image/jpeg'

if art:
    audiofile.tag.images.set(3, open(art, 'rb').read(), art_ext)
    audiofile.tag.save(version=(2,4,0))

[ksperling]

IIRC for iTunes you want v2.3 and ensure the image description is not empty (eg set it to “cover” or something like that).

…

On Fri, 5 Jun 2020 at 07:19, chemicalwill ***@***.***> wrote: @ksperling <https://github.com/ksperling> I am trying to do this with iTunes as well as Groove. What args do you have to specify to 'play nice' with the artwork? I'm new to file handling with python so please forgive me if this is a dumb question if art: audiofile.tag.images.set(3, open(art, 'rb').read(), art_ext) audiofile.tag.save(version=(2,4,0)) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#343 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGB6LWS476EFEFK6JMR4YLRU7XSTANCNFSM4I62AD3A> .

[jonhnet]

I had exactly the same frustration as ksperling -- lots of debugging time wasted; ordinary users must just give up in despair.

Suggestion: have command line tool issue a warning that blank description field confuses buggy players (like itunes and my Toyota), suggesting to add dummy text in the description field. That should save users the interop frustration, but let the API stay clean.