APIC :: link to the image file by using the 'MIME type' "-->"

[ttimer]

Hi !

Is it a bug or a feature ? ;)

[ mutagen V1.43.0 - mid3v2 V1.3 ]

I tried to place a link with "mid3v2", but the picture was embedded also -- with "MIME type -->" !

Within "mutagen" I can't find a special handling for APIC links...

[ id3.org :: 4.15. Attached picture ]

... to put only a link to the image file by using the 'MIME type' "-->" ... The use of linked files ... since there is the risk of separation of files.

|
|-talking-book
 |
 |-**cover-apic-to-link-to.jpg**
 |
 |-CD01
  |-file001-w/o-embedded-pic--w/link.mp3 (*)
  |-file002-w/o-embedded-pic--w/link.mp3 (*)
  |-... (*)
  |-file020-w/o-embedded-pic--w/link.mp3 (*)
 |-CD02
  |-file021-w/o-embedded-pic--w/link.mp3 (*)
  |-file022-w/o-embedded-pic--w/link.mp3 (*)
  |-... (*)
  |-file040-w/o-embedded-pic--w/link.mp3 (*)
 |-CD03
 |-...
 |-CDxx
  |-filexx1-w/o-embedded-pic--w/link.mp3 (*)
  |-filexx2-w/o-embedded-pic--w/link.mp3 (*)
  |-... (*)
  |-filexx0-w/o-embedded-pic--w/link.mp3 (*)

(*) Instead of embedding the same picture many times, just link to it (--> ../cover-apic-to-link-to.jpg).

---

Sometimes you could spare 100 MB and more, especially with audio books.

Many thanks,

Juergen

[lazka]

You would need to write the URL you want to link to into the "image file". It seems you are trying to use relative file paths, while the standard only allows full URLs.

[ttimer]

Would you give me a pattern, please?

BTW, I tried both full URL and relative file paths -- and some other things too...

---

How does a full URL work, when the files are moved or the directories were renamed afterwards? Changing the ID3 tags every time wouldn't be very convenient...

[lazka]

To quote the standard:

There is the possibility to put only a link to the image file by using the 'MIME type' "-->" and having a complete URL [URL] instead of picture data. The use of linked files should however be used sparingly since there is the risk of separation of files.

I don't know how this is supposed to be used, as I've never seen it used.

[ttimer]

Yeah, that's what I saw in the mutagen code...
Maybe M. Nilsson (id3.org) will give a suitable solution. I'll ask him.

[ttimer]

No answer from Martin yet; but I found the following: ("hierarchical URI" looks interesting)

LINK - Linked information (ID3 Version: 2.3➔)

To keep information duplication as low as possible this frame may be used to link information from another ID3v2 tag that might reside in another audio file or alone in a binary file. It is RECOMMENDED that this method is only used when the files are stored on a CD-ROM or other circumstances when the risk of file separation is low. The frame contains a frame identifier, which is the frame that should be linked into this tag, an URI field, where a reference to the file where the frame is given, and additional ID data, if needed.

URI syntax (Uniform Resource Identifier) by examples:

URL (absolute URI) http://flying.guy.chez-alice.fr/index.htm http://java.sun.com/ ftp://blabla.com/ file:///C:/MyFiles/test.mp3

hierarchical URI java.sun.com MyMP3File.mp3 ../../OtherFile.mp3 SubDir/OtherFile.mp3

Data should be retrieved from the first tag found in the file to which this link points. A linked frame must to be considered as part of the tag and has the same restrictions as if it was a physical part of the tag (i.e. only one TALB frame allowed, whether it's linked or not).

Additional data needed: language descriptor for: ATXT, COMM, SYLT, USER and USLT. content descriptor or owner identifier for: AENC, APIC, COMM, GEOB, PRIV, SYLT, TXXX, USLT and WXXX. This is not a good idea to link ASPI, ETCO, GRID, LINK, MLLT, PCNT, POPM, POSS, SEEK, SIGN, SYTC, TIT2 or UFID. There may be more than one LINK frame in a tag, but only one with the same contents.   This help is mainly a copy of: http://www.id3.org/