Last modified: 2014-07-19 00:43:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 20252 - Support for WAV and AIFF by converting files to FLAC automatically.
Support for WAV and AIFF by converting files to FLAC automatically.
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: multimedia
  Show dependency treegraph
 
Reported: 2009-08-15 07:12 UTC by Charles Gillingham
Modified: 2014-07-19 00:43 UTC (History)
21 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Charles Gillingham 2009-08-15 07:12:19 UTC
Allow editors to upload audio files in .WAV or .AIFF format, automatically converting them into FLAC files under the covers and storing them in that format, fixing file extensions and other issues appropriately.
Comment 1 Derk-Jan Hartman 2009-08-15 11:01:52 UTC
adding Michael Dale to CC.
Comment 2 Chad H. 2009-08-15 11:08:57 UTC
Would need MW changes first, tweaking product and component.
Comment 3 Brion Vibber 2009-08-23 01:31:24 UTC
For playback support we'd probably need to generate compressed Vorbis streams as well.
Comment 4 Michael Dale 2009-08-24 20:20:00 UTC
ideally we can reach some consensus on how "non-free" & "non-in-browser playable" streams should be represented. The two posiblities are: 

1) We store the media in a temporary location, transcode it and then insert it into the site with the .ogv or .oga extension and never expose the original media to end users. The wikitext title Users would embed with the oga file: [[File:MyAudio.oga]] 
1a) disadvantage we don't give users access to the highest quality source and if people want to make modifications it will result in quality degradation. (not the case with flac but true for others) 

2) We should be doing something like what we do for .tiff where the original file is uploaded but when its "embedded" or "viewed" it gets transcoded/converted to free formats. The users would then embed the media with [[File:MyAudio.wav]] but inline it would point to the vorbis. If pulling up the original asset page they can download the original. This is more inline with our current approach for svg and large .pngs.
2a) This may be problematic with highly patented encumbered formats. h264 for example has per stream distribution costs not sure if we would run into that but maybe should be considered.. the original stream could be hidden in that case?
2b) This is confusing in terms of syntax. Your embed name includes .avi, .mp4 or .wav but maybe not so much of a problem because people will be using wizards to inject media and or is not *that* confusing given svg representation. 

I presently do option two in the transocode job extension. But option 1 and how described in this bug makes sense too. 

(the transocode job extension is presently called wikiAtHome since its supports distributing the job to the clients and will be used for the distributed rendering of sequences) 
Comment 5 Chad H. 2009-11-28 04:41:57 UTC
Mass component change for merge of "File/Repo" and "Images and Files"
Comment 6 Michael Dale 2012-11-09 05:55:57 UTC
should be noted option 2 was taken to address bug 39867
Comment 7 Marco 2013-07-03 21:30:17 UTC
(In reply to comment #0)
> Allow editors to upload audio files in .WAV or .AIFF format, automatically
> converting them into FLAC files under the covers and storing them in that
> format, fixing file extensions and other issues appropriately.

WAV is supported as of 8. July. Maybe the request to deliver lossless flac transcodes for low bandwidth users should be filed as a new bug.
Comment 8 Bawolff (Brian Wolff) 2013-07-03 21:33:57 UTC
> WAV is supported as of 8. July. Maybe the request to deliver lossless flac
> transcodes for low bandwidth users should be filed as a new bug.

I think you mean July 15 (July 8 is flac roll out). Note, it will be done by doing transcodes to vorbis, which is what a low bandwidth user would want. If you care about things being lossless, you are probably not a low bandwidth user.
Comment 9 Matthew Flaschen 2013-07-03 21:52:32 UTC
This bug suggests storing as FLAC under the covers (to save 50% storage space on the server) even when the real file is WAV (or AIFF), not delivering FLAC.  It's a good idea, but requires some design consideration.

I agree delivering FLAC should be a separate suggestion.  As Brian said, it's not that useful for low-bandwidth users, but could be helpful to some reusers.
Comment 10 Charles Gillingham 2014-07-11 19:02:18 UTC
The original motivation for this bug was to make it possible for audio professionals (such as myself) to upload files without having to learn to use a whole new set of unfamiliar tools. (Few recording artist know how to use the bash shell, for example)  If .WAV is now supported, then I think this enhancement should be closed. The goal is accomplished.
Comment 11 Quim Gil 2014-07-14 12:56:44 UTC
CCing the Multimedia team is becoming more complex as they grow.  ;) Anyway, what do you think?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links