On the fly ID3 tag conversions while copying

[porg]

I read your FAQ, specifically on what you are likely not to implement or surely never going to implement. But as I am not a developer by trade, and not at all familiar with how such virtual/filesystems work I nevertheless make a proposal, more than being rejected cannot happen 😉

Goal

• I want to keep the files in my Music.app unchanged
• I want the possibility for old mp3-players which require a certain ID3 format or the absence of ID3 to get the files transformed when copying.
• Ideally this is implemented in a manner that first iTunesFS only achieves the file listing not taking too much computation,
  • and only if a full read occurs (QuickLook or copy operation to MP3 player) then the operation takes place
  • So theoretically only the ID3 tags portion which needs to be translated on the fly.
  • I would not care if that initial listing lists a wrong filesize (because it is not yet aware of the transformation which occurs later) for the files
  • But ofc, this is how I imagine it idealistically, maybe this is anyhow not feasible.

Proposal

iTunesFs gets additional configuration parameters:

• ID3-conversion: off | on | strip-id3-altogether
• ID3-version = You can state the version number of the ID3 standard to which it should be converted.
• ID3-charset = The character set to which shall be converted.
• Possibly some other parameters get necessary which define what to do in regards to data-loss or data-transformations which need to happen as a consequence.

[Marcus Müller]

This would need to be added to IFSiTunesTrack's - (NSData *)fileContents method. I'm not interested in this feature but will accept patches.

[porg]

Thanks for your reaction that it is possible but that you won't do it.

Just to get an idea on the feasibility:

• For every directory that iTunesFS creates, the on the fly byte transformation (ca 100-500 bytes) per file, would need to run, in order to create that changes, and the impact on filesize would need to be updated? Would that difference be only in memory, or also persisted somewhere in a cache, that this does not need to run every time?
• Does this all need to be done during initialization recursively for the entire iTunesFS?
  • Or is there a possibility to delay this, and serve a quick slightly wrong info (wrong file size), and only on demand do that transformations and the consequential updates of the file sizes?

[Marcus Müller]

Just to get an idea on the feasibility:

* For every directory that iTunesFS creates, the on the fly byte transformation (ca 100-500 bytes) per file, would need to run, in order to create that changes, and the impact on filesize would need to be updated? Would that difference be only in memory, or also persisted somewhere in a cache, that this does not need to run every time?

I'd think that this heavily depends on the amount of work which is required. Considering that you only need this once per rsync-run, I'd probably do this on-the-fly. It really depends on how "expensive" this transform is.

* Does this all need to be done during initialization recursively for the entire iTunesFS?

No, - (NSData *)fileContents is called on demand only.

  * Or is there a possibility to delay this, and serve a quick slightly wrong info (wrong file size), and only on demand do that transformations and the consequential updates of the file sizes?

I suppose so. Files can change at any time so there is no guarantee per se that a previously given file size will remain constant.

[porg]

Cool. That on-demand-only ID3 transformation/stripping would be totally be fine.

• I'd make sure that rsync compares only by name, at max some timestamps,
• and ignore file-size changes, because they would mostly differ when the source contains "the richest possible ID3 tags" and the destination tendentially smaller ID3 tags or no ID3 tag at all.

A s1mp3 player that I own displays certain Unicode encoded files as garbled characters and crashes on any images contained in ID3 tags.

• So in this transformation I would change charset and strip the picture tag altogether.
• Or if that is transformation is too sophisticated, I would simply choose to strip the ID3 tag altogether, and embed all my desired tags into the filename with the nice filename scheme customizations that iTunesFS offers. Serves the same end goal too.