Add more id3 v2.4 support details.

[Sophist-UK]

Summary

This is a…

• Correction
• Addition
• Restructuring
• Minor / simple change (like a typo)
• Other

Reason for the Change

Give more info for Windows users.

Description of the Change

SoftPointer AudioShell 2

Additional Action Required

We could probably do with a special page covering support for various music and tagging formats under various software under various operating systems.

[rdswift]

I'm not disputing the information, but I'm not sure that I understand how it really applies to Picard and adds value to the documentation -- especially stating that an update from Microsoft is supposed to provide support but hasn't been verified. Can you help me understand? Thanks.

[Sophist-UK]

It adds value by helping users decide which version of ID3v2 tagging to use.

I have AudioShell 2 installed and my music is tagged with ID3v2.3 so I have no idea whether newer versions of WIndows 10 display ID3v2.4 tags in File Explorer or not. I suppose I can test it if you wish so we can make this statement a bit more definitive rather than totally wishy-washy, but without testing it on various back-level versions of Windows 10 (though I may have a virtual Windows 10 image of 1709 that I keep for a specific application) I am not sure that we can be completely definitive.

P.S. Regarding a special page covering support for various music and tagging formats by various players / file explorers, I still think it is a useful idea, but I suspect that the maintenance effort may be too large to be acceptable.

[rdswift]

Thanks. That helps. Also, I don't think it's fair to ask you to go out of your way to do any amount of testing.

P.S. Regarding a special page covering support for various music and tagging formats by various players / file explorers, I still think it is a useful idea, but I suspect that the maintenance effort may be too large to be acceptable.

Yeah, I need to think about that a bit. I see the potential value, but keeping it up-to-date would probably be a nightmare. It would really require input from users of all the different systems and software, and we haven't yet achieved any sort of critical mass of contributors to sustain what we already have. I'm afraid that it would rapidly become outdated and reflect incorrect information, and in my mind that's worse than no information at all.

@zas / @phw: Any comments on this PR and the topics raised in the discussion?

[Sophist-UK]

Yeah, I need to think about that a bit. I see the potential value, but keeping it up-to-date would probably be a nightmare. It would really require input from users of all the different systems and software, and we haven't yet achieved any sort of critical mass of contributors to sustain what we already have. I'm afraid that it would rapidly become outdated and reflect incorrect information, and in my mind that's worse than no information at all.

I am a great believer (as far as Open Source is concerned) that if you ask the community for help a significant part of it will step up to the mark.

So if we were to have such a page, we would need to encourage such involvement by heading it up with a statement that the page is entirely community written and supported and ask people to correct anything that they find is inaccurate and to add anything that they find is missing.

We could even give it a try and see (over the first 6 or 12 months) whether it gets supported or not, and if not we will remove it. And we could add a statement saying that this is a trial so please contribute.

[rdswift]

I am a great believer (as far as Open Source is concerned) that if you ask the community for help a significant part of it will step up to the mark.

I'd really like to believe that, but so far that has not been the case with this documentation project. I have repeatedly asked in the MetaBrainz Community Forum for people to have a look at the docs and let us know if they find something that is wrong, isn't clear, could be improved, or should be added. I'm not naive enough to think that it's flawless. So far, you are pretty much the only one that has responded.

I manually did the French translation by myself using Google Translate (because I don't speak French), and asked on the Forum for people to have a look and let me know where the translation is incorrect or could be improved. Not a single comment. Same thing with my call for volunteers to help translate into another language or act as translation leads. Nada.

So if we were to have such a page, we would need to encourage such involvement by heading it up with a statement that the page is entirely community written and supported and ask people to correct anything that they find is inaccurate and to add anything that they find is missing.

Okay, I'm prepared to give it a try, but suggest that we maybe include it as its own section (Appendix D) to make it a bit more prominent than including it in the configuration page that you originally suggested. Would a title / topic of "System / Player Compatibility" or "Browser / Player Tag Compatibility" be appropriate? This could then provide a chart or listing of the systems and players and the relevant configuration settings and other notes to have Picard properly tag the files to work with that system / player. This appendix could then be referenced in the appropriate locations throughout the rest of the document, such as "configuration" and "troubleshooting". What do you think?

We could even give it a try and see (over the first 6 or 12 months) whether it gets supported or not, and if not we will remove it. And we could add a statement saying that this is a trial so please contribute.

To get a sense of the level of support, perhaps we could start a new topic in the Forum stating that we'd like to include this information in the Picard Documentation, explain what information we're looking to include, and ask the Community to provide the input to develop the initial page / section? People could provide their input there and we could transfer it to the new appendix once there are a few entries to make it worthwhile (and continue to add as the information comes in). We would also know who responded so that we could be sure to add them to the list of contributors in the documentation. Do you think this has a chance of working, or do you have another suggestion?

[rdswift]

The content of such a section might be something like:

Browser Name (os platforms)

Picard Configuration Settings

This would include things like tag type and any other relevant settings such as embedding coverart, etc.

Notes / Considerations

This could include things like recommended best practices, or information such as your note about Windows 10 update possibly correcting an issue.

---

Player Name (os platforms)

Picard Configuration Settings

This would include things like tag type and any other relevant settings such as embedding coverart, etc.

Notes / Considerations

This could include things like recommended best practices, or information such as your note about Windows 10 update possibly correcting an issue.

---

If we could quantify the information types provided, we might be able to put it in a table, but that could be problematic because of limited page width. That's why I ended up formatting the tag mapping the way I did.

[Sophist-UK]

I was thinking more about a simple table - music file format across the top, o/s & app down the side - cells containing details of what is supported.

As for getting people to contribute, it is all about how you pitch it - here is what I might say...

"We would like to help more people use Picard more effectively by helping them understand how they can utilise the tags in their music files that Musicbrainz and Picard generate. And this page is our attempt at doing this. HOWEVER...

The Picard applications is entirely written and supported by a small number of unpaid volunteers - what we can do is limited by how much help we can get. In particular we do not have the time or resources to document every application that can be used to look at or play the files tagged by Picard or how to configure Picard and these applications to make best use of the metadata.

This is where YOU come in...

If you want to find out what software works best with Picard tagged files, please feel free to use this page to find out what other people have tried (hopefully avoiding re-inventing the wheel). If in the end you find that your own experience is NOT documented here, please please pay forward the help you got by updating this page with your own experiences in order to help other people in the future.

And of course, if you want to contribute to improving other pages of this documentation, or help with Picard / Picard plugin development, or to help maintain the massive Musicbrainz database of metadata that drives the whole process, then your help there would also be very welcome."

[rdswift]

I was thinking more about a simple table - music file format across the top, o/s & app down the side - cells containing details of what is supported.

Something like the following (sample data not verified but for demonstration purposes only), or were you somehow intending to intermix the file formats like WAVE, MP3, etc.?

	ID3v2.3	ID3v2.4	APEv2	RIFF
Windows Explorer	X	Note 1		X
MediaMonkey	X	X	X
Foobar2000	X	X
DeaDBeef	X	X

Notes:

1. Windows 10 Creators Update v1703 onwards is supposed to support the reading and display of ID3 v2.4 tags in Windows Explorer, though this has not been verified. In earlier versions of Windows, support in Windows Explorer can be added using
   SoftPointer AudioShell 2.

---

As for getting people to contribute, it is all about how you pitch it - here is what I might say...

Sounds good. How much in the Appendix page, and how much in the Community Forum posting?

[Sophist-UK]

Yes - a bit like that table but...

Columns: mp3 ID3v2.3, mp3 ID3v2.4, FLAC, AAC etc.

But I do worry that the learning curve for Github and the markup language might be too steep - perhaps a sticky community topic where people can document their experiences less formally using some basic template and we can then add to our page every so often based on that.

[rdswift]

Columns: mp3 ID3v2.3, mp3 ID3v2.4, FLAC, AAC etc.

You do realize that there are currently 22 file formats supported, comprising 34 different file extensions. Depending how you look at it, that's either 23 or 35 columns, including the first column specifying the browser/player. Not exactly conducive to display as a table on a web page.

But I do worry that the learning curve for Github and the markup language might be too steep - perhaps a sticky community topic where people can document their experiences less formally using some basic template and we can then add to our page every so often based on that.

That's actually what I had in mind, to make it as easy as possible for people to contribute.

I still don't know how we would effectively show this as a 35 column (or even 23 column) table without massive scrolling. This becomes even worse as the table becomes longer (more lines), because the scroll bar shows at the very bottom of the table on the web page, and the user will typically lose track of which line they are trying to track if they have to scroll it off the screen to get to the horizontal scroll bar. That is why I ended up reformatting the mapping table in Appendix B.

We could offer this as a spreadsheet or stand-alone web page, which is what I have done with the tag mapping information. The links are shown in the opening paragraph when displaying the Appendix B page in the on-line User Guide.

The information is maintained in a Python file and the spreadsheet, stand-alone web page and restructured-text file for the User Guide (website, epub and pdf outputs) are rebuilt automatically whenever an update to the site is published. @phw and I reviewed our options for presenting the information in a tabular format and this is what we decided to use. This also makes it fairly easy to maintain and check the information before publishing. Perhaps not ideal, but it does offer the users three different alternatives for viewing the information -- each with its own strengths and weaknesses -- so they can choose which best suits them. All this while we only have to maintain the information in one place.

[phw]

I basically agree with what Bob has been said above.

So far we have mostly avoided having too much detail information about specific third party software in the documentation. But we have a few places where it made sense. E.g. on the same page we have specific option for grouping / work saving the iTunes way, and we mention MusicBee for this setting as well because it is the most prominent example of handling it the non-iTunes way.

So yes, Windows bad ID3v2.4 support is probably the most important reason why we still have v2.3 as default, even though you can only recommend everyone who uses software and devices supporting v2.4 to switch this option. So it makes sense to have a few words about it.

Two things I would change:

1. I would display the Windows information in a note:: section, as we do it for MusicBee.
2. The statement should be a bit clearer and less vague. It should be possible to at least verify that a current version of Windows 10 does support v2.4 tags.

In regards to having a full list of players with their supported features I am very sceptical. This would become stale very quickly, and I would not even be sure where to start or end. Do we list file formats? Tag formats? Audio codecs? Individual supported tags?

What maybe would work would be a case listing typical gotchas. Kind of a special player FAQ, listing only known oddities and limitations that have an effect on tagging and maybe require special consideration or Picard settings.

[phw]

Shouldn't we better link to https://www.softpointer.com/AudioShell.htm instead? This gives an overview over what this thing is, which I think makes it easier for the user to decide if they want this or not.

[Sophist-UK]

Shouldn't we better link to https://www.softpointer.com/AudioShell.htm instead? This gives an overview over what this thing is, which I think makes it easier for the user to decide if they want this or not.

Yes - we definitely should. My mistake.