Extension Size

[TheDirtySpaceman]

Another thread had me examining the size of the music files them self and weighing the quality vs. size options of managing an extension such as this. The first thought I had was why not take advantage of Google's REST API to dynamically access the files from the google drive folder instead of having every user download them to local storage.

Something as simple as a request resource in a URI should be very simple to implement. There are pros and cons to this.

Pros:

• File size of the extension would drop dramatically, to a few Kbs most likely.
• Files would have a centralized source outside the repository (git is for text anyway)
• Files could be of a higher bitrate/quality

Cons:

• I'm not sure how many people use this extension. Multiple people asking for a file at the same time from the source may cause load times if there isn't enough bandwidth.
• HTML5 Audio objects have a preload setting for buffering the files from remote sources, but I'm not sure of the performance.
• The music would not play without an internet connection.

This is a short list but either way I believe it is a worthwhile pursuit. It would involve a few steps:

1. Remove all local file system resources
2. Code their retrieval into URIs using the Google Drive.
3. Adjustments for best load time/quality of sound: a. Find highest lossless versions of music b. Tweak with encodings/bitrates c. test load times/buffering into the HTML5 audio objects
4. profit???

In the end if the REST api calls prove to be too slow, the music will still have quality adjustments and size reduction.

Thoughts @JdotCarver @kylechu ???

[kowsen]

I think you've pretty much nailed it with the pros and cons - I'd be super interested to see if this works well. It would be a great alternative to destroying the audio quality.

My only fear that I'd want to add to Cons is that I feel like this has a reasonably high chance of breaking seamless looping, but if this works well it will be worth it.

I'd love to see a small webpage as a proof of concept, showing that you can pull one of these audio files from the Google Drive folder and play it in an HTML5 audio object before I get too excited about this concept though.

[TheDirtySpaceman]

Of course, an isolated function prototype would be necessary for testing anyway.

[BordenJardine]

I'm sure one could find a way to keep seemless looping. It might require using the audioBuffer objects instead of the

There are probably other places to host the files if google drive doesn't work out

[TheDirtySpaceman]

audioBuffer is only supported officially by firefox FYI though, its webkit in chrome. I'm not sure that approach would be great when the portability of the code comes into play.

[TheDirtySpaceman]

The HTML5 object has a preload setting to ask the DOM to buffer the file onload and timeRanges property for seeing which sections of the file are buffered currently, I bet we could make it work.

[BordenJardine]

the entirety of the web audio API works in chrome http://caniuse.com/#search=audiobuffer

The town tune player already uses the audio buffer extensively. Not saying we have to use it, but we shouldn't be worried about portability :)

With the web audio API, you get all of the same things the audio tag gives you without having to create a DOM element, plus you get quite a bit more control of the sound. You could do things like buffer the next song before the current one finishes, and the fade-in/fade-out logic would be a lot simpler with the web audio gain nodes.

Not trying to dictate anything, I just work with the web audio api a lot, and I think it is fun to use.

[TheDirtySpaceman]

Not at all! That's good information, I was just trying to remain neutral and generic in the design and mozilla developer network had chrome compatibility listed as experimental.

If it's being used already though definitely take it into consideration.

It may even allow a refactor of the setTimeout implementation for looping the songs.

Anyway I think I'm going to do a few webpage mockups and do some testing.

[kowsen]

I tried setting up a quick test to see if this could just be done through direct links to the audio files in the drive folder. Sadly, though it seemed to work for a bit, it looks like once I made more than a few calls in a row to grab that audio file, I was blocked from playing it any more. :(

Here's my code in case it's useful to anyone. Note that when you click on the button, it takes up to a few seconds for the audio to buffer, so give it a bit before you give up on it.

WebAudioTest.zip

[BordenJardine]

Aww, nice effort! Maybe we could try hosting someplace else? Amazon s3? Is there like a free place to host a few hundred megabytes?

[TheDirtySpaceman]

I'm not sure the hosting is the issue. The way he is requesting the file is not the way I suggested. But I'm not sure that the results would vastly improve or not. It seems strange that when you access the drive through a browser the download is way faster than his example. Theoretically it should be slower.

Harold Houchin

On Jan 29, 2016, at 9:01 AM, BordenJardine notifications@github.com wrote:

Aww, nice effort! Maybe we could try hosting someplace else? Amazon s3? Is there like a free place to host a few hundred megabytes?

— Reply to this email directly or view it on GitHub.

[kowsen]

Yeah, I thought I could get away with the quick and dirty option, but no luck. I'd be really interested to see how much better your method performs - or if Google Drive is designed not to let us do something like this.

Though looking at how the REST api works, it looks like you might need to download the entire file before beginning playback, which is concerning to me - but maybe I'm misunderstanding the documentation.

[mn6]

Going to look into creating a fast audio streaming server for this.

[PikaDude]

Closed in PikaDude/ac-music-extension-revived/pull/16