Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI cover description and type #64

Closed
git-anish opened this issue Apr 23, 2021 · 9 comments
Closed

CLI cover description and type #64

git-anish opened this issue Apr 23, 2021 · 9 comments

Comments

@git-anish
Copy link

hey,

how do I go about setting the "type" and description value of an image using the CLI utility?

typically its passed in the same line such as cover=/path/to/file.jpg:FRONT_COVER:album art

in this case the cover would be file.jpg, its type would be FRONT_COVER and its description would be "album art"

@Martchus
Copy link
Owner

Looks like I really have never needed and therefore never implemented this. Making this work via the syntax you're proposing would be easy to implement.

@git-anish
Copy link
Author

git-anish commented Apr 23, 2021

great, thats the syntax from eyeD3

its a useful feature incase you want to avoid overwriting existing images in mp3s since setting a different type and description from existing images avoids overwriting them in eyeD3

I saw the GUI has the feature so I thought it might have already been implemented in CLI

thanks for getting back to me!

@Martchus
Copy link
Owner

in mp3s/m4as

I assume you mean MP3 files and MP4 files. Note that MP4 tags (iTunes tag format) do not allow to set multiple covers of different types and there's also no support for a description - at least not to my knowledge. This feature is in fact only supported by ID3v2 tags and Vorbis Comments. (And cover images in Matroska files are a whole different story anyways.)

I saw the GUI has the feature so I thought it might have already been implemented in CLI

The GUI and CLI are not fully equivalent. I simply implemented certain features where I needed them or considered them most useful.

@Martchus
Copy link
Owner

I've been implementing the feature and updating the README. Note that extraction by cover type is still missing.

@git-anish
Copy link
Author

Hey! testing this out now, how do I ensure existing covers are not overwritten when adding new covers?

I saw a few examples that you'd set to remove them but not to keep them

@Martchus
Copy link
Owner

Martchus commented May 6, 2021

Existing covers should actually be kept by default (unless --remove-other-fields is specified). This is what I mean with "Other cover types are not affected." in the README. Of course only one cover per type is possible and as already mentioned this is not supported by MP4 tags (where therefore the type is ignored and the previous cover can not be preserved).

If it isn't yet working as intended it would be helpful to know the command you've been using so I can reproduce with less effort.

@git-anish
Copy link
Author

git-anish commented May 6, 2021

I'm trying this on MP3s only
tageditor set title="A" album="B" albumartist="C" disk=1 genre="D" year="2021-05-06" comment="E" cover0=~/1.jpg:front-cover:2 -f ~/1.mp3

tageditor set title="A" album="B" albumartist="C" disk=1 genre="D" year="2021-05-06" comment="E" cover=~/1.jpg:front-cover:1 -f ~/1.mp3

either of these commands will overwrite the existing covers even if their descriptions are different

I guess I'm used to eyeD3, it allows for multiple images in the same type and doesn't overwrite covers if descriptions are different under the same type.

I can confirm that setting a different type (back) does ensure existing (front) covers won't be overwritten. This is enough for my purposes, thanks again!

@Martchus
Copy link
Owner

Martchus commented May 6, 2021

The standard actually says that there might be different covers with only different descriptions:

Description is a
short description of the picture, represented as a terminated
text string. There may be several pictures attached to one file, each
in their individual "APIC" frame, but only one with the same content
descriptor. There may only be one picture with the picture type
declared as picture type $01 and $02 respectively.

I assume "content descriptor" means combination of the type and description.

So the way eyeD3 handles it is correct and I should likely adapt the tag editor.

Martchus added a commit that referenced this issue May 10, 2021
…ions

The standard actually says that there might be different covers with only
different descriptions:

    Description is a
    short description of the picture, represented as a terminated
    text string. There may be several pictures attached to one file, each
    in their individual "APIC" frame, but only one with the same content
    descriptor. There may only be one picture with the picture type
    declared as picture type $01 and $02 respectively.

I assume "content descriptor" means combination of the type and
description.

This is in accordance with eyeD3.

See #64 (comment)
@Martchus
Copy link
Owner

This should actually work now with 1944773.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants