Support for WAV and AIFF by converting files to FLAC automatically.
OpenPublic

Description

Author: cgillingham1

Description:
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.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=32135
https://bugzilla.wikimedia.org/show_bug.cgi?id=46610
https://bugzilla.wikimedia.org/show_bug.cgi?id=14373

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz20252.
bzimport created this task.Via LegacyAug 15 2009, 7:12 AM
TheDJ added a comment.Via ConduitAug 15 2009, 11:01 AM

adding Michael Dale to CC.

demon added a comment.Via ConduitAug 15 2009, 11:08 AM

Would need MW changes first, tweaking product and component.

brion added a comment.Via ConduitAug 23 2009, 1:31 AM

For playback support we'd probably need to generate compressed Vorbis streams as well.

bzimport added a comment.Via ConduitAug 24 2009, 8:20 PM

mdale wrote:

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)

  1. 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)

demon added a comment.Via ConduitNov 28 2009, 4:41 AM

Mass component change for merge of "File/Repo" and "Images and Files"

bzimport added a comment.Via ConduitNov 9 2012, 5:55 AM

mdale wrote:

should be noted option 2 was taken to address bug 39867

McZusatz added a comment.Via ConduitJul 3 2013, 9:30 PM

(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.

Bawolff added a comment.Via ConduitJul 3 2013, 9:33 PM

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.

Mattflaschen added a comment.Via ConduitJul 3 2013, 9:52 PM

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.

bzimport added a comment.Via ConduitJul 11 2014, 7:02 PM

cgillingham1 wrote:

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.

Qgil added a comment.Via ConduitJul 14 2014, 12:56 PM

CCing the Multimedia team is becoming more complex as they grow. ;) Anyway, what do you think?

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:29 PM

Add Comment