Bump default audio stream quality setting

[Hitrate]

As you can see from the frequenzy analyzer, audio through ninjam/ninbot/jamtaba is really crappy for lack of a better word, especially in the highs. Look at those spikes above 15k and how it drops off...there's basically no audible quality above 15k only noise due to low quality stream settings.

I find it a no brainer to bump the quality to max for all users of jamtaba, asap for next release. No point in running at those low quality settings where it sounds like a bad encoded 64kb 22khz sample and asking people to adjust their json settings is a bit far fetched. I know there will people the odd person arguing against that due to some people running on ISDN modems, but I'd like to see some proof that there is even one complaint about there being too much traffic for them to be able to jam - I just don't see the real world scenarios of people not being able to run a simple jam through their internet connection due to "too high audio quality stream". I know the argument could be made in 1996 but I have a feeling it's a personal preference thing and not based on real world experiences. So ya, long story short unless there is significant proof most people want low quality streams as it is now, I think it should be bumped ASAP !

[elieserdejesus]

I tried an experiment here:

1 - I generated a white noise (all frequencies with equal level) wave file in Audacity.

2 - Imported the white noite wave file in Reaper and put and Spectrum analyzer in Reaper master output. As expected, the spectrum is flat in the high end:

3 - Imported the same white noise wave file in JamTaba (Standalone) looper. This is my "Xmiter" in this experiment.

4 - Changed Xmiter audio encoder to low quality and connected in a server.

5 - Started ReaNinjam as the receiver connected in the same server. Now I'm receiving the white noite, but encoded in ogg vorbis with low quality.

6 - As expected, the spectrum is showing the dropped high end frequencies:

7 - Changed the audio encoder quality in Standalone (the Xmiter) to High Quality and checked the spectrum again. Using high quality in audio encoder we have more high end frequencies (maybe up to 18 KHz).

8 - As a last effort to reach 20 KHz I changed the code to encode in the most high super duper quality in ogg vorbis, and I can see no significant improvements in the spectrum:

My conclusions:

1 - I agree with @Hitrate, It's a good idea use the High Quality as default value in JamTaba audio encoder (at moment we are using the Normal quality as default), we will see a little (but good) improvement in the general audio quality, maybe improving from ~15KHz to ~18KHz.

2 - The ogg vorbis is imposing a ~18 KHz limitation, so use the super duper highest quality make no sense in ninjam world. Using the max quality we will generate big audio streams but with very little difference in the audible spectrum, maybe something like change from ~18 to ~18.5 KHz.

[jonjamcam]

Well as as a matter of fact I would do the opposite (set default quality to Low). The reason is that in my opinion the average user in ninjam couldn't care less about quality of the music they make, so why offer such a good quality. The idea of having quality options rests on the principle i think that good music needs good quality, so imo the best encoding quality should be a special bonus for people who care, not for everyone. I Believe the average user should sound as reaninjam. Level field.

On the other side of this argument we could redefine normal and high quality. Normal could be 0.3 (the actual value of high) and high could de raised to 0.4 or 0.5 which have Fuller sound (Although the frequency response is the same as Eli said).

(http://wiki.hydrogenaud.io/index.php?title=Recommended_Ogg_Vorbis)

Just my 2 cents.

[Hitrate]

Well if everyone sounds like crap, how do you think that will effect the sound of the musicians?

I must say I couldn't disagree with your post any more strongly. It sounds like you have some sort of personal vendetta towards people who seek high quality music and jams, or that you yourself are one of those that couldn't care less about quality of the music they make. It's not something I've heard uttered by any ninjammer ever, that they coould care less about quality of the music they make. Last time I mentioned this topic, your response was that it'd reflect back badly on Jamtaba, if people dropped out due to too high bandwidth stream. Which doesn't make any sense in 2018 given how little bandwidth audio streams draw anyway and how fast internet has become.

Now the reason is that you don't think users care about and deserve high quality...Usually with these kind of things in the real world, people have to prove these sort of statements, or else there is really no basis for it's consideration, because it's just personal opinion not backed up by facts.

I could claim all ninjammers love high quality audio and would respect the format and other players, play and sound much better etc. if the developers respected their ears and provided high quality streams instead of squashed dynamic and frequency range.

Really, if your statement holds any water let's turn down the quality to 56k, all mono channels. Most users don't care about stereo, why offer it as a standard? People should earn their right to stereo, or at least be geeks like us and change the settings themselves in the json..... See how that doesn't make any sense?

[Hitrate]

Anyway back on the topic of high(er) quality,

As you see on the picture, there are specific spikes in the audio above 15k, like it's badly decoded or something...If you look at your last screenshot elisier, those spikes are not there - meaning there's less introduced jitter and stuff in the high register (result: cleaner audio) so I don't know how you don't see any significant improvement.

However, apart from the default audio quality, I think that frequency cutoff is a point of focus as well:

How do we avoid this high freq cut off ?

What's causing it in the first place?

How do we optimize the stream quality so we don't get artifical sounding highs ?

I will have to do more research, but so far I can not seem to find where ogg vorbis as you claim imposes an 18khz limitation...Where is this limitation coming from? It's not the container itself that has this limitation, so it must have to do with quality settings of the app/server/the encoding/decoding or converters..

"As Ogg Vorbis is a more recent format than MP3 (version 1.0 of Ogg Vorbis came out on Monday, 8 May 2000), it provides better sound fidelity, in the frequency range of 8kHz-48.0kHz. "

[elieserdejesus]

As you see on the picture, there are specific spikes in the audio above 15k, like it's badly decoded or something

If your spectrum analyzer is inserted in the master these spikes can be harmonics generated by your local input. Your local input is not encoded when sended to the master output, so the spectrum will show all (not filtered yet) harmonics.

I don't know how you don't see any significant improvement.

I don't see significant improvements in the last experiment only, I recognize the improvements in the other scenarios.

How do we optimize the stream quality so we don't get artifical sounding highs ? Change from ogg to something different, perhaps more futureproof and efficient?

Change the encoder is my desire too, but unfortunally this is not a JamTaba issue, this is a ninjam ecosystem issue. If we use another audio encoder (something easy to do in the code) all other clients will not render JamTaba xmited audio. Changing the encoder all other non JamTaba users will always hear "no audio", just silence, because all received audio streams are using a strange "format" for the old clients. Only JamTaba will be able to handle the new format.

"As Ogg Vorbis is a more recent format than MP3 (version 1.0 of Ogg Vorbis came out on Monday, 8 May 2000), it provides better sound fidelity, in the frequency range of 8kHz-48.0kHz. "

Agree, I never readed something about 18 KHz limitation in ogg vorbis, but my experiment described in this issue is replicable and is showing an empirical detected issue, even using very high quality in the encoder. So, in theory there's no limitation, but in practice the spectrum analyzer is showing another thing. Since I'm not a huge fan of ogg vorbis I prefer believe in the spectrum analyzer 😄 .

[jonjamcam]

I must say I couldn't disagree with your post any more strongly

That's ok. Torben. Everyone is entitled to their own opinions, so am I. I'm mostly a contributor of ideas here. I don't impose my point of view, so please stop attacking me when I disagree with you.

Well if everyone sounds like crap, how do you think that will effect the sound of the musicians?

That's you saying that. I don't think everyone sounds like crap. To clarify, I'm talking about the average user and it's my experience, could be different for others

[Hitrate]

14. Audio Example S.The effects of 128kbps CBR MP3 encoding show the 16kHz brickwall HF roll-off, and added fluctuating frequency content around and in between the original tones, resulting in clearly audible artifacts.

That sounds like what's happening here...https://www.soundonsound.com/techniques/what-data-compression-does-your-music

This explains the 18khz cut off that I wasn't aware of... : http://ixbtlabs.com/articles/oggvslame/index.html

Would it be technically possible if we get a hold of the people in charge of the "ninjam ecosystem" to make a change to a better encoder or would that require a whole new approach to how ninjaming works behind the scenes ?

Jon: yes, but what good are ideas if they're not well described and reasoned for? I feel like I'm trying my best here to describe how such a "world view" is counter productive, as it leaves people who do care about high quality, even if they're not audio geeks, in the dust and the ones that could care less actually win... If you could explain why you feel the ones that could care less should win, then perhaps I and other people could understand why and where your ideas are coming from. Why not force everyone to only stream in MONO. Ninjammers could care less about about stereo since they could care less about audio quality... I hope you see how ideas such as those are not really helpful, if anything they're counter productive since the topic of debate is the poor quality of current state, not whether or not we should have even lower quality (and to add to the matter you where the one to set the standard of the 3 quality levels, so if anything you should have set it lower back then unless you've changed your opinion since then?) If your goal is to have things be at a low level, I feel like a thorough explanation of why that should be the case, is needed, not just disagreeing for the sake of disagreeing.

[jonjamcam]

Torben. I think I was clear enough in my previous posts. Sorry, but I don't have anything else to contribute with regards to this issue.

[elieserdejesus]

Would it be technically possible if we get a hold of the people in charge of the "ninjam ecosystem" to make a change to a better encoder or would that require a whole new approach to how ninjaming works behind the scenes ?

The bottom line is Cockos. To change the encoder is necessary convince Cockos to change the ReaNinjam code and the ninjam server code. But I think most public servers are using modified versions of Cockos code, so it's not easy change this "ecosystem", but is possible.

[Hitrate]

Hello again, so everyone would have to have same jamtaba or nijnjam setups to make it work, with modified quality settings... Would it be possible to do this if I provide the server, and everyone in the room are using the same "modified" Jamtaba client? What else would be needed to change, since I wouldn't think ReaNinjam or Cockos would need to have anything to do with it, other than perhaps a fee to use their software?

[elieserdejesus]

Hi Torben, I can think in 2 ways.

In both ways is mandatory change JamTaba client to encode audio using another codec (it's not a simple task)

1 - The bad idea: Just host a new ninjam server and warning people (maybe using a fixed topic in the server) about the new audio codec and the usage of a modified client. People using old clients will "hear just a lot of silence".

2 - The good idea: Change the server code to accept only modified clients (wahjam is doing something like that). Old clients can't connect in the server. If I remember correctly the server can return an error message from disconnected clients, this can be usefull to "spread the news".

At moment I'm not active in this project, so we need wait some contribution. I have no time to dive in the audio codec details at moment.