adding Michael Dale to CC.

Would need MW changes first, tweaking product and component.

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

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)

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)

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

mdale wrote:

should be noted option 2 was taken to address bug 39867

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

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.

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.

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.

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