Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 03-18-2019, 03:25 PM   #1
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default 5.973 ReaNinjam Client Transmit Issue

The ReaNinjam Client seems to mess up samples transmitted to a Ninjam Server. This leads to an audible crack/click with a periodicity of the Ninjam interval.

How to reproduce:
-----------------
* Log into any Ninjam server with two computers both running Reaper with its built in ReaNinjam client.
* Send audio from computer #1 to server, best is a clean sine (e.g. ReaSynth) to hear the crack easily.
* Listen to audio on the other computer #2. Hear crack at about every interval length.

Tested with:
------------
* Different Ninjam servers: public server at ninjamer.com, private server V0.06, private server V0.071 (freshly compiled from source)
* on Win 10 64bit PC
* on iMac
* different networks, different routers, different firewall rules (incl. allowing all types of ICMP traffic)

Why is the root suspected in Reapers's native ReaNinjam client:
---------------------------------------------------------------
* When using the very old stand alone client
https://www.cockos.com/ninjam/downlo...client_006.zip
on computer #1 while still using ReaNinjam on computer #2:
- computer #2 now receives pristine audio sent from computer #1
- computer #1 still receives crackling audio sent from computer #2

=> problem must be in current native ReaNinjam client, not in the server, network or elsewhere

Thanks for looking into this issue!
brummbear is offline   Reply With Quote
Old 03-19-2019, 04:21 PM   #2
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

I found an older thread which seem to be related to this very issue. Same symptom with only ReaNinjam having the issue, not the stand alone client:

https://forum.cockos.com/showthread.php?t=45580

Maybe related too (I can confirm the clicking and also the obvious spikes in the spectral view:
https://forums.cockos.com/showthread.php?t=27864
brummbear is offline   Reply With Quote
Old 03-19-2019, 07:41 PM   #3
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 3,978
Default

Confirming :-(

There are clicks in audio signal right at interval boundary. Look at waveform - one sample at the end of interval is off.




https://stash.reaper.fm/35861/reanin...-click-bug.jpg
akademie is offline   Reply With Quote
Old 04-19-2019, 01:54 PM   #4
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

Can we temporarily solve the problem like follows?

1. Identify the version of Reaper when the problem did not yet occur (5.xx)
2. On Windows*: Replace reaper_ogg.dll and/or reaninjam.dll in the current installation path with the files from the older version

Question: Which of the two files is the main contender to cause the issue?

* On Mac: same as 2a with whatever are the corresponding files/libraries there
brummbear is offline   Reply With Quote
Old 04-20-2019, 07:28 AM   #5
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Hmm what samplerate is the audio device using, and what BPM/BPI is ninjam set to? It might be related to that (if it is, probably also affects the old clients too).
Justin is offline   Reply With Quote
Old 04-20-2019, 04:04 PM   #6
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

Computer #1 audio interface at 48kHz/24bit
Computer #2 audio interface at 48kHz/24bit
Ninjam server as well as both Reaper instances on computer #1 and #2 are all set to the exact same values


BPM/BPIs tested:

120bpm/4bpi
120bpm/8bpi
95/4bpi
88/4bpi

This was tested with computer #1 being a PC with Win 10 64bit and computer #2 being an iMac pro (friend's device). On both machines the problem was clearly reproducible, i.e. the audio coming from the other machine has clicks at interval boundaries. So, if computer #1 transmits a sine user #1 hears a clean sine whereas user #2 hears the clicking in the audio sent from computer #1. Same problem the other way round.

Important to note that if one side uses the old stand alone ninjam client the audio sent to the other computer is clean gain (see initial problem description). This makes me think the problem is related to how the ninjam client transmits audio to the server.

If you think it would be helpful to find the root cause I could:
* Set up a test environment with two Windows machines (I don't have a Mac)
* Create a simple test project
* Test with different audio interface settings
* Test with older/modified dll versions (client or ogg)
* Upload test project, ninjam session files to stash
...
brummbear is offline   Reply With Quote
Old 04-20-2019, 06:35 PM   #7
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

I suppose it could also be that the Vorbis version that ReaNINJAM uses is newer, too.

Edit: I dug into this, looking at the old standalone client, and comparing various behaviors.

Some thoughts:

1) The discontinuity is somewhat expected the way that Vorbis is used (a new encoder is initialized without the same context as the previous block).

2) The discontinuity is obvious with a sinewave, but with more reasonably musical content, it's less of a problem.

3) The vorbis encoder in the standalone client has a *LOT* of issues. While it has less obvious discontinuity, it still has some, and it also can't represent a sine wave very well (it adds a ton of other noise).

I'm pretty sure the difference you're hearing is the fact that the Vorbis encoder was improved since the standalone client has been released, and those improvements mean better audio quality, at the expense of discontinuity at the intervals.

Anyway, those are my thoughts. At some point maybe I'll try linking reaninjam with the ancient vorbis encoder of NINJAM v0.6, or NINJAM v0.6 with Vorbis 1.3, to compare. But meh.

Last edited by Justin; 04-20-2019 at 07:31 PM.
Justin is offline   Reply With Quote
Old 04-20-2019, 08:54 PM   #8
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

While I don't believe in telepathy.... I was just about to suggest this as I felt the Vorbis compression could be to blame indeed:

* Let me test with all participants on a LAN without any compression (how do I disable ogg vorbis entirely?)
* Can we use an older version of Vorbis?
* Ideally: Allow the nerdy users to set Vorbis compression parameters (default values as today). Including no compression at all. Would also be very welcome when doing private server sessions with few participants and lots of internet bandwidth

PS: and yes, I think you are right about the audio quality in general. It has improved relative to the older versions but the clicking is ruining it. Not so noticeable with distorted guitar, drums etc but brutal with some synths and even vocals.

PPS: the discontinuity seems harmless with some audio when you look at it in the time domain. But switch to spectral view. Bright highlights over the entire spectrum like someone inserted a dirac pulse. Really surprising actually considering the tiny blip in the time domain. I attached an arbitrary snapshot from an older session. Maybe not the most obvious, but still visible and audible.
Attached Images
File Type: jpg ninjam_spectrum.jpg (48.0 KB, 164 views)

Last edited by brummbear; 04-20-2019 at 09:22 PM.
brummbear is offline   Reply With Quote
Old 04-20-2019, 09:41 PM   #9
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Perhaps the NINJAM client can be updated to use crosslapping from here: https://xiph.org/vorbis/doc/vorbisfile/crosslap.html

Supporting anything more than that (including uncompressed) would likely require updating the NINJAM protocol and breaking compatibility.

As for saving your jams in full quality -- all participants can choose to save .wav files, then you can share them after the fact.
Justin is offline   Reply With Quote
Old 04-20-2019, 11:23 PM   #10
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

Hmm - the cross lapping sounds like worth trying!

I was not really aware until now that Ninjam treats every interval as an "independent" ogg container file, i.e. a stream without the context of preceding & succeeding streams. Please excuse my previous ignorance: I was originally thinking of a gapless continuous stream - physically segmented, but still one stream keeping context. But now, looking at the actual file structure this starts to make sense indeed. Ninjam encodes every interval as individual Ogg Vorbis stream and during decoding concatenates individual streams (= clips) into a continuous stream.

Thus, calling ov_crosslap() at the interval (= individual stream) boundaries should heal/improve those discontinuities
https://xiph.org/vorbis/doc/vorbisfile/ov_crosslap.html

Since this only affects the decoder it sound relatively safe to not break anything. While the root cause lies in the way Ninjam uses Vorbis to encode each interval individually (rather than keeping context, which may be possible too but sounds like a bigger and riskier change) cross lapping in the decoder may be good enough.

Rg the save to wav file option: That's something I tried many years back, but it did not work properly at the time. I do not remember exactly but I think the wav files had the stereo messed up (channels would flip intermittently). I gave up, but will revisit this in one of the next sessions (maybe resolved now?).

Thanks, Justin, for digging into this!! Reaper has given me countless numbers of joy (with or without clicking :-), best piece of SW ever - seriously.

Last edited by brummbear; 04-21-2019 at 09:38 AM.
brummbear is offline   Reply With Quote
Old 04-21-2019, 02:56 AM   #11
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 3,978
Default

Quote:
Originally Posted by brummbear View Post
...
Rg the save to wav file option: That's something I tried many years back, but it did not work properly at the time. I do not remember exactly but I think the wav files had the stereo messed up (channels would flip intermittently). I gave up, but will revisit this in one of the next sessions (maybe resolved now?).
...
Yes, this is serious bug, locally saved WAV files (not sure now about OGGs locally saved?) from any ninjam session (normal jam or Session Mode) are in fact mono (L or R channel only, I don't recall which one, but I think it is right channel that is duplicated to both channels of stereo file!!

I don't think it was addressed in some newer versions of Reaper.
And would be great to have it fixed ... as it is especially useful in Session Mode

I will post links to existing threads about that bug later, because we have an all family lunch here now :-)

akademie
akademie is offline   Reply With Quote
Old 04-21-2019, 06:34 AM   #12
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Got it, fixing the stereo .wav file writing, thanks!
Justin is offline   Reply With Quote
Old 04-21-2019, 02:14 PM   #13
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

The next ReaNINJAM will automatically crosslap the audio to reduce the artifacts (something almost equivalent to ov_crosslap(), but slightly less-good, but it should be VASTLY better).

For purposes of importing clipsort.log, I think we can make the .ogg to .wav generation do that crosslap too (which will mean you'll need to have it render the oggs to wav to benefit from it, which I think we can all live with?).
Justin is offline   Reply With Quote
Old 04-21-2019, 02:39 PM   #14
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 3,978
Default

Quote:
Originally Posted by Justin View Post
Got it, fixing the stereo .wav file writing, thanks!
Wow, great. Thank you Justin.
akademie is offline   Reply With Quote
Old 04-21-2019, 02:51 PM   #15
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 3,978
Default

Quote:
Originally Posted by Justin View Post
The next ReaNINJAM will automatically crosslap the audio to reduce the artifacts (something almost equivalent to ov_crosslap(), but slightly less-good, but it should be VASTLY better).

For purposes of importing clipsort.log, I think we can make the .ogg to .wav generation do that crosslap too (which will mean you'll need to have it render the oggs to wav to benefit from it, which I think we can all live with?).
Will importing of clipsort.log as OGG files still stay as an option (even with possibility of "clicks")? (I hope it will stay!).

Then yes, I think it could be acceptable solution.

EDIT: It would be good to make some info in importing dialog (like in "Do you want to convert to WAV? Can improve clicks at intervals" ... or something like that, so it is obvious, that there is differency between OGG/WAV, to eliminate false bug reports of some kind in future by misunderstanding tech.aspects of two imports..

Last edited by akademie; 04-21-2019 at 02:58 PM.
akademie is offline   Reply With Quote
Old 04-21-2019, 03:44 PM   #16
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

Quote:
Originally Posted by Justin View Post
The next ReaNINJAM will automatically crosslap the audio to reduce the artifacts (something almost equivalent to ov_crosslap(), but slightly less-good, but it should be VASTLY better).

For purposes of importing clipsort.log, I think we can make the .ogg to .wav generation do that crosslap too (which will mean you'll need to have it render the oggs to wav to benefit from it, which I think we can all live with?).
Sounds like a reasonable compromise limiting the required code changes. From a purist point of view the best would be to tackle the problem at the source, i.e. avoid clicks at encoding time. But that would require drastic code changes. The compromise will still provide a much better live listening experience and leaves two options for after the fact processing.
1. Use concatenated, cross-lap rendered Vorbis clips
2. For high quality use the (to be) fixed wav save files (and exchange locally stored saves between parties)


EDIT: @ Justin: It sounds like you prefer writing your own cross lap algorithm rather than relying on the Vorbis lib. I imagine you still have to extrapolate the end of the first clip and/or beginning of the second clip at a boundary to have some overlapping audio to smooth out. Would maybe vorbis_synthesis_lapout (https://xiph.org/vorbis/doc/libvorbi...is_lapout.html) be a good starting point?

Quote:
Will importing of clipsort.log as OGG files still stay as an option (even with possibility of "clicks")? (I hope it will stay!).
@akademie: I think it would be easy to keep the current option of importing the clips without any rendering. Just out of curiosity: Why would you want individual clips anyways? To write your own inter-boundary cross lap script? The individual Vorbis clips/"streamlets" are in any case only a synthetic representation of the original sound and the algorithm seems to have a weakness with the very last sample (looking at your previous screenshot).

Last edited by brummbear; 04-21-2019 at 04:10 PM.
brummbear is offline   Reply With Quote
Old 04-21-2019, 04:09 PM   #17
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 3,978
Default

Quote:
Originally Posted by brummbear View Post
...
@akademie:Just out of curiosity: Why would you want individual clips anyways?...
Because of disk space, quick loading of clipsort.log, fast rearranging interval items etc.
To be honest, I never use WAV conversion while working with clipsort.log and I prefer it that way much of the time, but also I would like to have an option to use WAV conversion when problems with boundaries would be to prominent/noticeable or something like that.
akademie is offline   Reply With Quote
Old 04-21-2019, 04:14 PM   #18
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

5.974+dev0421 has these improvements (fixed stereo .wav writing, crosslapping of incoming playback, crosslapping when concatenating to .wav on clipsort.log import). After making this build, though, I made some tweaks to the crosslap code (simplifying the crossfade shape and making the import fade length consistent with ReaNINJAM's playback) for the following build, so +dev0422 will differ slightly.

akademie: You can still use the non-wav importing of clipsort, and the prompt mentions quality benefits of converting to .wav. It might be possible to add a mode to REAPER where the imported OGGs get extended with the lapout data, and crossfaded within the UI to the next item, but I'll save that for another day.

brummbear: We don't use VorbisFile within NINJAM so we can't (easily) use the ov_crosslap() API, but yeah I've implemented it using vorbis_synthesis_lapout() and a trivial fade. I've pushed this code to the public ninjam git repository, in case anybody wants to improve on it... It's also made a little tedious by the fact that ReaNINJAM doesn't include libogg/libvorbis directly, it gets its encoder/decoders from our reaper_ogg.dll...
Justin is offline   Reply With Quote
Old 04-21-2019, 04:40 PM   #19
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 3,978
Default

Quote:
Originally Posted by Justin View Post
...
akademie: You can still use the non-wav importing of clipsort, and the prompt mentions quality benefits of converting to .wav. It might be possible to add a mode to REAPER where the imported OGGs get extended with the lapout data, and crossfaded within the UI to the next item, but I'll save that for another day.
...
That's perfect, Justin :-)
akademie is offline   Reply With Quote
Old 04-21-2019, 05:05 PM   #20
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

Wow, that was fast! Will try out later tonight
brummbear is offline   Reply With Quote
Old 04-21-2019, 08:42 PM   #21
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

I haven't tested the wave save fix yet, currently only focusing on:

+ ReaNINJAM: improve sound quality at end of each interval (=cross lap when listening live)
+ NINJAM: crosslap .ogg files when concatenating to .wav files from imported clipsort.log

Unfortunately neither one works yet over here.

BEFORE test with 5.974_public:
* Clips (non rendered):



* Concatenated clips (rendered):



AFTER test with 5.974_dev0421:
* Clips (non rendered):



* Concatenated clips (rendered):


A few observations:
* The rendering pushes the discontinuity back in time (2-3 samples in 5.974 and 7 samples in 5.974_dev0421)
* The rendering can change the slope of the discontinuity from falling to rising. EDIT: see below, this is simply due to the faulty sample always sitting at zero crossing
* In 5.974_dev0421 the rendering with cross lapping appears to even amplify the discontinuity. EDIT: see below, this is simply due to the faulty sample always sitting at zero crossing

The clicks are also audible during live play.

At least with the tested sine signals it seems that the Vorbis codec only messes up the very last bit of the clip. If this is universally true for any signal then this could be the path for a remedy. I.e. when cross lapping this last sample could be ignored for extrapolation (lapout) and actually be replaced by an extrapolated one. Or maybe ("back to the drawing board") the last sample is already replaced at the encoding stage with a better value...

EDIT: Oh, wait! Maybe we are even closer to a solution than thought: At a closer look it appears that the rendered discontinuity is a single sample sitting exactly on the zero crossing line (which also explains the seemingly amplified discontinuity as the signal is pushed further out and thus farther away from the zero crossing in my example) => just a tiny quirk in the code that should be simple to fix (!?) I mean, a quirk which was in the code even before the improvement with cross lapping (look at the screenshots). It seems that the new lapping improves the transition (slopes are now very neatly matching), but the big fat click comes from that one sample sitting on zero crossing, that existed before too when the slopes where just slightly off.

Last edited by brummbear; 04-22-2019 at 12:33 AM.
brummbear is offline   Reply With Quote
Old 04-22-2019, 12:31 AM   #22
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

well, here is the test report on the 3rd change of 5.974_dev0421:

+ ReaNINJAM: fix writing of stereo .wav files of local streams [p=2124239]

The stereo is WORKING now.

Now the interesting (or frustrating) part:

The individual wav clips contain the exact same blip in the last sample as the ogg clips => does this suggests that the vorbis encoding is not the root cause, but rather the wav that is fed into the encoder?

ogg clips:


wav clips:



Rendering from clipsort.log has the same effect as before, i.e. one single sample sitting on zero crossing.


brummbear is offline   Reply With Quote
Old 04-22-2019, 06:42 AM   #23
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Hmm I keep trying but I still can't duplicate those zero trailing samples.
Justin is offline   Reply With Quote
Old 04-22-2019, 07:05 AM   #24
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

I am on the go and cannot test for a few hours, but.....

Could this be a 32 bit vs 64 bit problem (code / PC architecture)???

I mean, both the fact that it is always the last sample in the file and that zero after rendering look suspicious. Samples are 32bit float, aren't they?
brummbear is offline   Reply With Quote
Old 04-22-2019, 07:05 AM   #25
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Aha, OK at 44100Hz and 117 BPM I did get some interesting results.

1) The zero samples at the end of the items you're seeing -- if you disable item looping, they should no longer be visible. The sample you're seeing is the item looping back to the start.

2) At 44khz/117 bpm/4bpi, each interval is 180,923.077 samples long.

3) If importing the .wav files directly -- REAPER imports the .wav files assuming their length is exactly the interval length and after 8 of these intervals the fractional sample offset exceeds 0.5, so it ends up skipping a sample during playback at the 8th, but not sooner. This can be likely fixed by having the clipsort.log import code place the intervals not exactly on the grid, but instead on their appropriate sample time.

4) The concatenation code currently rounds incorrectly, which causes the zero samples to be inserted into every interval (oops). This also has the disadvantage of making the timing drift off by (up to) a sample every interval. There is an obvious fix for this which we'll do for the next version.
Justin is offline   Reply With Quote
Old 04-22-2019, 07:09 AM   #26
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

my testing was done at 48kHz, 95bpm, 4 bpi

going offline for a few hours
brummbear is offline   Reply With Quote
Old 04-22-2019, 07:28 AM   #27
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by brummbear View Post
my testing was done at 48kHz, 95bpm, 4 bpi

going offline for a few hours
Yeah that would also do it (121,263.15 samples per interval, etc).

I've implemented the #4 fix above, which requires a little bit of lossiness but mitigating the quality issues.. #3 is trickier because you have to balance preserving timing of audio and continuity. I might leave it unaddressed for the time being and make you use #4 if you care
Justin is offline   Reply With Quote
Old 04-22-2019, 11:16 AM   #28
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

#4 fix is certainly the highest on my wishlist - thank you, Justin!

In its current state, if you pick a whole-numbered number of samples per interval e.g. 80bpm/4bpi/48kHz -> 144,000 samples per interval, the import with concatenation-rendering yields clicks whereas plainly importing the clips without rendering is click free. Ironic

Question: Will the #4 fix also affect the live listening experience or does it only address the import?

Last edited by brummbear; 04-22-2019 at 11:36 AM.
brummbear is offline   Reply With Quote
Old 04-22-2019, 12:43 PM   #29
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Hmm the only way I've been able to get clicks with 0421 and live listening is to use resampling (e.g. where the remote is sending 44k and I'm running 48k), which I'm fixing... The intervals do get a little bit of crosslapping artifacts but not much here. Tried various bpms and using a sinewave to test + listening and a spectrogram to validate
Justin is offline   Reply With Quote
Old 04-22-2019, 01:19 PM   #30
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

This is so odd. Just to reconfirm I just ran a new test again:

Computer#1(Win10, 64bit, 5.974_dev0421): 48kHz,24bit. Reaper set to 80bpm, 4/4. Normal Ninjam.
Computer#2(Win10, 64bit, 5.974_public): 48kHz,24bit. Reaper set to 80bpm, 4/4. Normal Ninjam.
Ninjam Server: 80bpm, 4bpi

Computer#2 sends clean sine wave to server.
Computer#1 produces audible clicks at interval boundaries! Project settings/Playback Resample Mode sits at "Good (192 Sinc)" - shouldn't matter anyways.

I should add (as stated in the initial post) that during live listening the local audio does not produce any clicks, just the received audio. Somehow the Ninjam client must introduce these discontinuities at interval boundaries when it puts the received audio onto the master. Does the Ninjam client doe anything similar to what you are doing when concatenating during clip import, i.e. a similar rounding error sort of thing?

EDIT 2: I stand corrected on my earlier statement that with whole numbered samples per interval there is no click when importing without concatenation. The received audio still clicks, i.e. both during listening as well as after import.

Last edited by brummbear; 04-22-2019 at 01:29 PM.
brummbear is offline   Reply With Quote
Old 04-22-2019, 01:43 PM   #31
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by brummbear View Post
This is so odd. Just to reconfirm I just ran a new test again:

Computer#1(Win10, 64bit, 5.974_dev0421): 48kHz,24bit. Reaper set to 80bpm, 4/4. Normal Ninjam.
Computer#2(Win10, 64bit, 5.974_public): 48kHz,24bit. Reaper set to 80bpm, 4/4. Normal Ninjam.
Ninjam Server: 80bpm, 4bpi

Computer#2 sends clean sine wave to server.
Computer#1 produces audible clicks at interval boundaries! Project settings/Playback Resample Mode sits at "Good (192 Sinc)" - shouldn't matter anyways.

I should add (as stated in the initial post) that during live listening the local audio does not produce any clicks, just the received audio. Somehow the Ninjam client must introduce these discontinuities at interval boundaries when it puts the received audio onto the master. Does the Ninjam client doe anything similar to what you are doing when concatenating during clip import, i.e. a similar rounding error sort of thing?

EDIT 2: I stand corrected on my earlier statement that with whole numbered samples per interval there is no click when importing without concatenation. The received audio still clicks, i.e. both during listening as well as after import.
I tested this exact setup, with a 180Hz sinewave, and in stereo, this what the live results look like:


The interval boundaries are barely audible, the levels in the spectrogram are -73dB at 500Hz, -100dB at 1khz, -125dB at 4khz. I find this to be acceptable.

For reference, here is a recording of the output in WavPack - https://1014.org/_/ninjamtest1.wv
Justin is offline   Reply With Quote
Old 04-22-2019, 02:06 PM   #32
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

Lol - I did the same thing while you were posting

I recorded the output of Ninjam for a sine at a slightly higher frequency than your's. Spectrogram:



It is a bit more audible than your example (I think because of the steeper slopes of the sine), but arguably one could say "live with it".

here is the wavpack:
https://stash.reaper.fm/36153/02-190422_1345-glued.wv

Last edited by brummbear; 04-22-2019 at 02:15 PM.
brummbear is offline   Reply With Quote
Old 04-22-2019, 02:26 PM   #33
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Posted +dev0422 with more stuff
Justin is offline   Reply With Quote
Old 04-22-2019, 02:35 PM   #34
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

here is a more comparable picture for my sine test with better resolution using your excellent JS:



quite a bit more energy in those blips (green pronounced horizontal stripes in each of those peaks).
brummbear is offline   Reply With Quote
Old 04-22-2019, 02:40 PM   #35
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

Quote:
Originally Posted by Justin View Post
Posted +dev0422 with more stuff
COOL!
brummbear is offline   Reply With Quote
Old 04-22-2019, 02:49 PM   #36
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by brummbear View Post
here is a more comparable picture for my sine test with better resolution using your excellent JS:



quite a bit more energy in those blips (green pronounced horizontal stripes in each of those peaks).
Those blips are pretty low volume, if you mouseover you can see the levels.
Justin is offline   Reply With Quote
Old 04-23-2019, 05:29 AM   #37
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

Rg live listening:
I think the artifacts at interval boundaries for incoming audio are something driven by the concept and have to be accepted.

Rg import for later remixing:
This can be improved for the ogg clips by cross lapping (and fixing #4 "zero sample bug"). When using wav clips it is already click free (the wav option is only available for the local source, however).

I tested 5.794_dev022 and observed:
a) #4 "zero sample bug" seems fixed
b) the transition at the boundary (a few samples left and right from boundary) is butter smooth - looks perfect!
c) the "fade in" on the right of the boundary is very strong => this re-introduces almost as much of a spectrum error as we had without cross lapping (see images). It is very audible.

I think we are really close to a great sounding solution. Only the cross lap / cross fade needs a tiny optimization. We may need a more complex shape (equal power?) of the cross fade and/or have to (drastically) shorten the lap and fade area. The latter seems justified because the sloping errors introduced by the Vorbis encoder seem fairly harmless (we were initially mislead by the image of the last sample which in fact was the first sample coming from the loop source option in Reaper). I would suggest to try either equal power or maybe just ~16 samples of lapping...

Imported clips without concatenation:


Zoomed without concatenation ("loop source" OFF this time ):


Spectrum without concatenation:


Imported clips WITH concatenation -> strong fade in:


Zoomed WITH concatenation -> buttersmooth around boundary, no more "zero sample":


Spectrum WITH concatenation -> oops

Last edited by brummbear; 04-23-2019 at 10:19 AM. Reason: more specific language for ogg vs wav clips
brummbear is offline   Reply With Quote
Old 04-23-2019, 05:49 AM   #38
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 3,978
Default

Ahh boys, great "laboratory work" here. I am sorry that I can't keep up with you, while you are so fast working on resolving the problem. I will add some testing when I will not be so busy. Thank you for the attitude and the amount of work you are putting in this.
Hat down! :-)
akademie
akademie is offline   Reply With Quote
Old 04-23-2019, 09:12 AM   #39
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

Quote:
I would suggest to try either equal power or maybe just ~16 samples of lapping...
I amend my suggestion: Cross fade should not be equal power. The signals are 100% correlated, hence it should be linear.
brummbear is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 12:42 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.