|Resolved||kaldari||T120288 Enable MP3 uploads on Wikimedia Commons and TMH playback|
|Resolved||TheDJ||T115170 Add support for MP3|
|Resolved||kaldari||T162395 Add .mp3 to the list of accepted file types on Wikimedia Commons uploads|
|Open||None||T132650 Copyright detection (acoustic fingerprint matching) for audio files|
|Resolved||CKoerner_WMF||T167815 Conduct MP3 patrol discussion|
|Resolved||kaldari||T180002 Create new "MP3 uploaders" user group on Commons|
|Resolved||CKoerner_WMF||T176782 Communicate enabling MP3 uploads on Wikimedia Commons|
- Mentioned In
- T162395: Add .mp3 to the list of accepted file types on Wikimedia Commons uploads
T168128: Install MP3 encoders and decoders on Tool Labs
T167815: Conduct MP3 patrol discussion
T166024: Once it's not patent-encumbered, enable MPEG-2 support for Commons uploads and TMH/etc. playback
T45149: Commons uploads: Support automatic conversion of mp3 formats to free format
- Mentioned Here
- T180002: Create new "MP3 uploaders" user group on Commons
T162395: Add .mp3 to the list of accepted file types on Wikimedia Commons uploads
T167815: Conduct MP3 patrol discussion
T132650: Copyright detection (acoustic fingerprint matching) for audio files
T164914: Add ID3 metadata fields to the metadata on File description pages
T115170: Add support for MP3
Once the switch is flipped on the server right? I've collected some interesting patents (these are probably more significant than MP3 though):
Agree with @Base, this should not be enabled on Commons unless a reviewing interface is built (similar to CopyPatrol) or the right to upload mp3s is restricted to a subset of users (at least to begin with). It is extremely difficult currently for Commons volunteers to review audio for copyright violation. If the world discovers that Commons is now a free mp3 hosting service and we have no way to patrol what is being uploaded, we will quickly have a crisis on our hands that is worse than selfie-pocalypse.
^ I've filed T167815: Conduct MP3 patrol discussion just in case. This is a task to be coordinated through the Community Liaisons team in the Foundation. @Elitre will need some time to identify scope of work and assignees.
It's possible that patroller consensus arrives at a different conclusion, but I agree there's a heightened risk and we can and should further discuss potential threats and countermeasures.
I'm an eventualist as much as the next person, but if we wait for a copyright violation tool to be developed we may be waiting a long time. That makes me sad that we'd potentially miss out on a sizable amount of useful content.
What if we approached this in phases?
Phase 0 - Uploading MP3s is a user right (that the Commons folks could help us figure out the requirements for) initially. Uploads are only allowed by folks in this group. Maybe figure out a way to tag/track these uploads for accountability? Idea stolen from kaldari's comments above. T120288#3343239. I could help with the outreach on this to Commons.
Phase 1 - A tool is developed that perhaps an expanded group could use to patrol. This sounds something that might be accomplished via a Project Grant. Dispenser mentions a few services that make make this possible: T132650#3273150
Phase 2 - An inline tool in the upload process that everyone uses. It checks every upload and never makes a mistake. :)
There's probably more details in here than what I described, but what do others think?
@CKoerner_WMF: I like your plan and think it would make sense to present something like it to the Commons community for discussion. My suggestion for the implementation of phase 0 would be:
- Create a new user right (upload-mp3)
- Either create a new user group for that right on Commons or assign it to the existing user groups "Administrators" and "Image reviewers"
- Add a check for the user right to all the uploading interfaces (probably can just modify UploadBase::verifyUpload() or something similar)
We probably don't want to hack mw core only to add this. AF might be better suited for this.
Using AbuseFilter for this would be great from a developer point of view, but would suck for end users. Imagine going through all the steps in Upload Wizard only to be told that your upload was rejected (since AbuseFilter is only triggered at the last stage of uploading). I'm pretty sure there's a hook for adding valid mime-types and there's also an UploadVerification hook in verifyUpload(), so this could be handled by an extension (rather than in core). Maybe the UploadWizard extension (although it's a bit of an awkward fit since this will affect non-UploadWizard uploads as well).
@CKoerner_WMF I think the most important thing that needs to be understood here is that any decision to enable mp3 uploading on Commons that is not implemented as the result of a explicit decision by the Commons community is likely to end badly. Now that the legal issues have been cleared up, and it's established that the technical implementation is not a problem, most of this discussion really needs to move onwiki, so that the community as a whole will have an 'investment' in the process of deciding how it is implemented. If a plan such as yours (which is not bad) is presented to the community as a 'fait accompli', even if merely for discussion, there will be grumbling.
If the decision is presented to the community as a request for them to 'rubber stamp' a process that has been predecided, not only will it get complaints at the time, but if there are issues then the WMF is likely to be blamed. It's unfortunate, but realistic.
It been 7 months since MP3 decoding support dropped in RedHat Fedora Linux, Chromium (the FLOSS fork that doesn't support H.264) will now have MP3 support. Will Wikipedia be the last Open Source project to get MP3 support?
Since all browsers will have playback support (no need to transcode). I suggest before Wikimania (Aug 9) we allow .mp3 uploads T162395.
Simply adding playback to a FLOSS desktop app is vastly different that adding support for uploads and management (patrol etc) of mp3s. One has real on-going human time impact (patroling etc), the other doesn't. Please don't be so dismissive.
@Keegan I've research and built tools for audio related uploads due to the Wikipedia Zero piracy problem. I have an IRC bot which fingerprints the audio track of audio and video files and lists acoustid.org matches. I also have an agreement with ACRCloud (strings attached) to scan music. I think that Wikipedia's use as a piracy host (for non-zero users) is lessened with easier free listening on YouTube (or Pandora or Spotify). This directly address @greg patrolling comment where he alludes to T167815.
@kaldari I tested python-acoustid to work with an MP3. The bot posts results to #wikimedia-commons-admin and ##wikimedia-commons-newbie-av on Freenode. Its hastily built (just to see if anyone wanted it), runs in anti-nuisance hourly updates, and I added Acoustid to see how well it works. It'll be converted it into a web tool so admins can delete and patrol without opening windows and at their convenience.
Per the previous discussions on Commons, I started an RFC to settle the question of which user groups should initially be allowed to upload mp3s: https://commons.wikimedia.org/wiki/Commons:Village_pump#RFC:_Which_user_groups_should_be_allowed_to_upload_mp3s.3F
So there wasn't a clear consensus on what groups should be allowed to upload to commons, but it seems like the idea with the most support is:
- Create a new "MP3 uploaders" group
- Give it the following permissions to start with: Not be affected by IP-based rate limits (autoconfirmed), Upload files (upload), Overwrite existing files (reupload)
- Allow admins to assign users to the new user group
- Create an edit filter that limits mp3 uploads to users that are either admins or MP3 uploaders.
I created a new task (T180002) to deal with the new user group.
To ask the question explicitly ...
This requested change will be to allow MP3 files for Commons alone. Other wikis that wish to have MP3 files will need to explicitly request MP3 files be allowed through a separate RFC. [In contrast to MP3 files are going to be allowed for all wikis, and Commons needs a means to better manage this, hence this process and discussion.]
MP3 uploading and playback is now working on the Beta Cluster: https://commons.wikimedia.beta.wmflabs.org/wiki/File:Chopin-waltz-op-69-no-2-in-b-minor.mp3. Transclusion and playback from other Beta Cluster wikis is also working: https://simple.wikipedia.beta.wmflabs.org/wiki/Piano.
If there are no issues, we can turn this on for Commons during the next SWAT window.