audiojs / audio-loader Goto Github PK

Hi @dfcreative,

I've just tried to use the new audio-loader 0.6.0 and I took more than 10 seconds to install on my computer... And I don't think that's a good user experience, so I would love to solve it.

The only solution I can find is split this module in two: one for browser and other one for node, but I'm open to suggestions.

What do you think?

I cannot be sure this is not a problem actually with the wavesurfer.js library I am using, or something with my usage of the audio-loader library.

I created one same audio file, and encoded it into WAV and into MP3 aswell. Then loaded it using:

var load = require('audio-loader')

load('./test-media/test-bleep.mp3').then(function (audioBuffer) {
     wavesurfer.loadDecodedBuffer(audioBuffer);
});

When I load a WAV file, it displays and plays fine. Here the output with a test wav file:

When I load an MP3 file, however, the file sounds one octave lower (I would guess), I presume it is interleaving channels that are actually present one after another.
The same audio, loaded as MP3:

If I load a musical track, I get the track, playing at half speed, with some artifacts, and the first half of the track is playing on one speaker while the second half is playing from the other speaker. The reported length, sampleRate and numberOfChannels is nearly the same when loading MP3 than WAV.

I would suppose that I am doing something wrong, since such issue hasn't been reported. I think that is still useful to post this as bug in order to reflect how I was expecting the system to work. If I find the source of the error, I will post it.

Hello
I'm using this
load('http://path/to/file.js').then ..
to load midijs soundfont

Any way to bundle my sound in the js file like this?
import SoundJs from 'path/to/file.js'
load(SoundJs).then ..

In some reason this test https://github.com/audiojs/audio-play/blob/master/test.js#L51 invokes callback three times

The audio signal returned for the same source encoded as mp3 and wav are quite different. I was expecting some margin of error, but in my case the [min, max] value range for the same source was decoded as [-0.554, 0.5936] and [-0.9917, 1.0000] respectively.

Hi @danigb!

I've been doing bits of refactoring here lately, mostly to freshen up the project and make node paths support, because absolute paths were not supported. Also I updated some dep packages, like audio-decode.

I've made a PR and it seemed to be fine, so I released the version 1.0. Not paying much attention I merged to master, merging the PR that way (my bad, but eventually that would happen :).
Can you please check the commits and if everything is fine - publish the npm module?

I'd also ask you for npm access to publish package later myself if you don't mind.
Appreciate!

Hi @danigb!

First off, thanks for the very nice module.
I am thinking to use it in upcoming audiojs/audio version, and audio-loader is almost perfect. One thing though — is it possible to make it work in nodejs?
I see right now you take ac as a first argument everywhere, but we use audio-context singleton to make that argument optional. That is suitable in case of nodejs, where having context is not necessary.

Appreciate any response.

Hi
I tried to load an audio from url

https://psv4.userapi.com/c611618/u55222772/audios/c60c5b828030.mp3?extra=BEO_kcoZRBWKevBsL-FqJjUU5aDMggaGl1UpnwC8wyUx0gaOmD5odL-TZhLpqe24kVFzGSrq4u8YSWwPlctkx2O-eG5oRGLwss1d5PKtrI3S2RFx52At0KlDs-Td53qhJRZR2036lMu8qVc

and got the error

{ [Error: ENOENT: no such file or directory, open 'https://psv4.userapi.com/c611618/u55222772/audios/c60c5b828030.mp3?extra=BEO_kcoZRBWKevBsL-FqJjUU5aDMggaGl1UpnwC8wyUx0gaOmD5odL-TZhLpqe24kVFzGSrq4u8YSWwPlctkx2O-eG5oRGLwss1d5PKtrI3S2RFx52At0KlDs-Td53qhJRZR2036lMu8qVc']
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'https://psv4.userapi.com/c611618/u55222772/audios/c60c5b828030.mp3?extra=BEO_kcoZRBWKevBsL-FqJjUU5aDMggaGl1UpnwC8wyUx0gaOmD5odL-TZhLpqe24kVFzGSrq4u8YSWwPlctkx2O-eG5oRGLwss1d5PKtrI3S2RFx52At0KlDs-Td53qhJRZR2036lMu8qVc' }

How can I prevent this error?
Thanks.

I imagine the case when some resource been loaded multiple times

load('./a.mp3').then(...)
load('./a.mp3').then(...)

How much sense is there to cache it for the second case?
Or it is better to delegate to outer wrapper, like audio?

This is mostly @audiojs issue, but I imagine cases where we don’t actually have complete buffer, but can get sequence of chunks. Example — soundcloud streams, or <audio> tag converted by web-audio-stream.

API seems to be similar to audio-loader in functional case:

let load = Loader(url);
load((err, chunk) => {}); 

Why it is tempting, it allows for listening soundcloud in terminal (in case if we make CLI for audio-components):

load url | speaker

Mb I really should address that to a separate module, like audio-load.

pretty please could you generate types.

Hi @danigb!

How do you hink, how much is it valuable to add loading from ArrayBuffer. AudioBuffer or TypedArray, basically just redirect to audio-decode for such cases?

That would generalize API coverage at no price and save code for audiojs/audio.

Though there might be a trouble detecting encoded or decoded ArrayBuffer.

Hi @danigb!

A bit audacious request, but what do you think about transfering this package to @audiojs? This package feels like a perfect fit for the org.
You still be the owner, author and admin of the package, but there will be other members able to maintain it (if you are absent, for example).
Also there will be automated greenkeeper/CI so package will be guaranteed be in workable state for the audio-* infrastructure.
Also there are plans for @audiojs website, similar to stack.gl, so in future it will be promoted online and have integrated docs.
That way it will be easier to look up/remember and broader public will get access to it.

Nonetheless I understand your wish to keep it as is.
Thanks.

Hi @danigb!

The 0.6.0 is awesome. One suggestion I have in mind.
Some modules oftentimes use callback as a last argument, along with promise (like decodeAudioData). We could do something like:

//cb style
load(url, (err, data) => {});

//promise style
load(url).then(data => {}, err => {})

That is not a big deal at all, but sometimes, like in case of pull-streams or fitting with other components we can ease connection by that, because node callback style (err, data) => {} is used de-facto, e. g.:

//some potential universal async audio reader
function read (cb) {
    load(url, cb);
    //↑ instead of ↓
    //load(url).then(data => cb(null, data), err => cb(err));
}

Just interested in your thoughts on that, Promise is completely fine too.

This works:

import play from "audio-play";
import load from "audio-loader";

load("./sounds/coin.mp3").then(audioBuffer => {
  play(audioBuffer);
});

But I want to encode the AudioBuffer to a string (so it can be stored in localStorage next time) and back again.

This does NOT work:

// Copied from  audio-loader/test/support/utils.js
function arrToBase64Audio(arr) {
  var data = new Buffer(arr).toString("base64");
  return "data:audio/mp3;base64," + data;
}

load("./sounds/coin.mp3").then(audioBuffer => {
  console.log(audioBuffer);
  const asString = arrToBase64Audio(audioBuffer);
  console.log(asString);
  console.log(asString.length);
  load(asString).then(ab => {
    //console.log(ab);
    play(ab);
  });
});

It says:

The buffer passed to decodeAudioData contains an unknown content type.