Recording: pre or post fader

[pljones]

One thing I noticed when comparing recordings between ReaNINJAM and JamTaba -- JamTaba levels seem lower.

My guess is that JamTaba is saving the data "post-fader" rather than the raw audio captured.

In my view, it would be much better to record the raw audio. Subsequent mixing is much easier that way.

However, I guess some people may prefer the "as I heard it" approach, so maybe another checkbox is called for?

[elieserdejesus]

@pljones , I checked the code (just to be shure) and the ogg vorbis data is not pre or post processed. The ogg vorbis data is received in NinjamController::on_ninjamAudiointervalCompleted and writed direct to file, no process, no decoding.

One thing I noticed when comparing recordings between ReaNINJAM and JamTaba -- JamTaba levels seem lower.

How are you comparing the records? Both clients are recording exactly the same audio streams?

[pljones]

Mmm, I've checked the code now and it does look right. I'll try again tomorrow to see if it was just how I was playing whilst testing -- I'll set up a recorded track or something more accurate (than me playing)! :)

[pljones]

Hi,

OK... I recorded a MIDI clip, then rendered through ReaNINJAM and JamTaba.

Track levels in both plugins claimed to be -12dB

Master level in ReaNINJAM claimed to be 0dB. JamTaba does not have a read out but I'd double-clicked the meter and it "reset".

According to Audacity, the peaks are: ReaNINJAM -19.94dB JamTaba -23.00dB

So the difference is quite noticeable.

Here's the rendered clips: http://peter.drealm.info/media/ThroughReaNINJAM.wav http://peter.drealm.info/media/ThroughJamTaba.wav

[elieserdejesus]

@pljones, maybe Reaninjam is processing the audio data before save (to create head room)?

[jonjamcam]

According to Audacity, the peaks are: ReaNINJAM -19.94dB JamTaba -23.00dB

Interesting. My tests show similar differences with a live input (floor noise):

EDIT: Izotope added to the comparison. Jamtaba is 3db lower against other vst:

[elieserdejesus]

I was considering the remote audio streams only, but now I see you are talking about the local audio streams. Now my first suspect is the pan law. @jonjamcam can you repeat your experiment with hard pan values (100% left and 100% right)? Stereo and mono input are showing some different values in db?

[pljones]

Yes, just to clarify, my recording was purely offline with ReaNINJAM and Jamtaba simply passing through the audio and applying their local channel processing.

[jonjamcam]

can you repeat your experiment with hard pan values (100% left and 100% right)?

Hard pan to left and right of the signal sent to the plugins show same behavior:

Hard pan of the plugin only (with stereo source) shows same problem:

Stereo and mono input are showing some different values in db?

Mono input same thing:

There is a correct display of the level in Jamtaba:

Conclusion:

Looks to me the input of Jamtaba has to be adjusted +3db to solve the issue. the reason why I can't tell it only happens with Jamtaba.

[jonjamcam]

Further analisis, now with remotes connected to a ninbot server. Three sources: Jamtaba, Jamtaba VST (repaer host) and Raninjam. The three are receiving the same input signal:

All levels at 0 (including reaninjam remotes). i can see different values in the input:

• [ ] In the case A, this shows the input levels both Jamtaba (VST and Standalone) are sending to Reaninjam. The received value is 3db below the expected value. This is the result of Both Jamtaba (VST and standalone) sending lower signal to Reaninjam by 3 dB. This is correlated with the experiments above https://github.com/elieserdejesus/JamTaba/issues/449#issuecomment-225942047
• [ ] Case B shows some differences. Here we can see what Jamtaba_VST is receiving (from Jamtaba standalone and reaninjam). In this case Raninjam is sending the correct level, but Jamtaba Standalone's signal is 3 db lower. This is also correlated with the experiments above https://github.com/elieserdejesus/JamTaba/issues/449#issuecomment-225942047
• [ ] In case C we see Jamtaba Standalone receiving correctly the audio from Reaninjam, but 3db lower in the case of Jamtaba VST. This is also correlated with the experiments above https://github.com/elieserdejesus/JamTaba/issues/449#issuecomment-225942047

Conclusion: Both Jamtaba VST and Standalone send Audio 3db lower to remote clients assuming the same input for all.

Now let's turn up the input for Jamtaba vst and standalone. The expected reult will be correct level for all clients:

As you can see all levels are OK now.

NOTE: My hypothesis is that the input level reaching both Jamtaba clients should be turned up by 3 db, not the output (done this only to prove the point)

[pljones]

With all faders at 0dB, there should be no maths being done on the samples before hitting the encoder. (Another reason to record at that point :).) If there is, that's a specific problem.

To be getting a -3dB gain applied sounds to me like there's some mixing being done. I just can't find the right pages with Google to work out what formula I'm expecting to find. "Linear gain" and "equal power" are the terms I think I'm after. I suspect it's something to do with the "channel groups" that I've not really investigated.

[elieserdejesus]

@jonjamcam , thanks for these details in your experiments.

I will investigate this problem in the next round (v2.0.16).

[elieserdejesus]

@pljones and @jonjamcam , I changed the code to auto generate input samples at fixed 1.0 (max amplitude). The expected result is 0 db, but the result is:

Owwww shit, hehehe :)

[elieserdejesus]

After commenting the code applying the pan law:

So, the pan law is the problem (or not, it's just a different pan law). In Jamtaba I choosed a pan law where we will have 0db in 100% left, 0 db 100% right, but -3 db in center. I tested here using every samples at 1.0 (0 db) and the results are ok:

I remember I choosed this pan law because sounds better in my ears when I started this project. If I remember correctly the idea is keep the perceived sound level equal in center and hard left/right.

[jonjamcam]

I choosed this pan law because sounds better in my ears when I started this project

I use the Pan control all the time and I agree that i sounds natural. I would keep the pan law, but normalize it to 0 db at the center. That means instead of:

L C R 0 -3 0

you get:

L C R +3 0 +3

[pljones]

I think the 0 -3 0 is "equal power"? That is, L+R total remains constant. Now, if L and R contain the same value, as with a split mono signal, that's going to be the case. With true stereo, however, it's not, as there are phase effects and other weirdness as the signal already has stereo position.

For a starting point, my view is that at centre pan, the outgoing signal should be bit-identical to the incoming signal -- ideally it should bypass any pan processing entirely.

Then, with a mono signal, ideally if you add the panned channels you should back get a mono signal that's bit-identical to the original unpanned signal.

Also note that the problem with allowing either L or R channel to exceed 0dB is clipping will happen, causing distortion.

I'm not sure on the best approach for stereo...

[jonjamcam]

With true stereo, however, it's not, as there are phase effects and other weirdness as the signal already has stereo position.

To avoid this problem the standard is to process monophonic audio with a PAN control (which move a mono signal across the stereo spectrum) contrary to a stereo signal which should be processed with a BALANCE control (raise or lower each channel level independently).

http://everything2.com/title/The+difference+between+balance+and+pan

Also note that the problem with allowing either L or R channel to exceed 0dB is clipping will happen, causing distortion.

I'm not sure if I understand your point about distortion @pljones . Are you suggesting that raising the level handle over the 0 dB can cause distortion?

Of course if the level is too high you can turn the volume down and distortion will dissapear. Remember we're talking about the pan law which operates post fader. I would agree with you if we were talking about raising +3db the input gain for which we don't have in Jamtaba a control, but in any case this would be true only for 16bit internal proccesing, not for Jamtaba that works in 32bit internal processing (as I understand it does).

[pljones]

If the +3dB on, say, the L channel reaches my DAC, it gets clipped, as far as I understand it.

[jonjamcam]

If the +3dB on, say, the L channel reaches my DAC, it gets clipped, as far as I understand it.

It won't if you lower by 3 db the master fader in Jamtaba. Your DAC will receive 0 db in this case.

[jonjamcam]

About the topic in question, Local tracks in Reaninjam are recorded pre-fader contrary to Jamtaba that records post-fader.

Reaninjam is part of reaper only (it can't be used with another host as you know), so it's input levels can be modified before they reach the plugin via reaper channels. In this case recording pre-fader is not an issue

Jamtaba on the other hand can be used in multiple environments and because it doesn't have an input gain control and can be used as standalone, recording post-fader is the best option IMO.

I think the VST version of Jamtaba could have a checkbox for pre-post fader if you need one, but the standalone version is better for me as it is now.

[pljones]

Recording and what you hear are, for me, different matters. Recording should be as unprocessed as possible -- I want the recordings for later, not now. I want them in as high fidelity as they can be, so that my subsequent use of them can have the best results.

On most platforms, Jamtaba itself not having input gain control should not be an issue. Most sound cards have channel gain controls (or go back and get the level right at source!). If the signal has clipped when it goes through the ADC, input gain control won't fix the clipping anyway.

[jonjamcam]

Recording should be as unprocessed as possible

The only way you get unprocessed recordings is storing the audio before it's compressed by the ogg algorithm. You can do this using the WAV format or any lossless codec like MPC or FLAC. I suggest you read https://github.com/elieserdejesus/JamTaba/issues/4#issuecomment-225876305 for discussions on this matter. Maybe we have a point of agreement on this issue.

So, once your signal is compressed by ogg mp2, mp3, etc. you loose important part of the original audio (most part I would say).

I want them in as high fidelity as they can be

So my point in this discussion is this: you are worried about some level difference of some db, but you are not addressing the more important issue of the complete modification of the original signal when it's processed for streaming.

See, lossy compression is a trade off in order for TV, radio, jamming, etc to be technically possible over the internet. You sacrifice studio quality of the sound the moment you send it over the net for technical reasons. I suggest you learn more about this topic reading articles like this one:

http://grahammitchell.com/writings/vorbis_intro.html

[pljones]

I have been suggesting capturing local audio as early as possible from the beginning of this discussion.

It's obvious you can't capture the received audio any earlier than it's received (!), so it will already be compressed. Those received ogg files are the best that can be captured (and are).

But both of those are not under discussion here.

This is about what you should hear.

[jonjamcam]

I have been suggesting capturing local audio as early as possible from the beginning of this discussion.

The title of this thread is "Recording: pre or post fader ".

Pre-fader is not the same as Pre-encoder. Pre-fader recording is post-Encoder recording as I understand.

[elieserdejesus]

@pljones and @jonjamcam , at moment the audio flow in Jamtaba is:

1 - Periodically Jamtaba receive raw audio chunks (128 samples, for example), from PortAudio (Standalone) or Vst Host.

2 - The pan law and gains (fader + boost) are applyed/computed in this raw audio. So, in this point the raw audio is not the same as original at 0db because current Jamtaba pan law is equal power (-3db in center).

3 - These gain processed samples are queued to vorbis encoder. The encoding is running in a background task. Since we have a bunch of vorbis encoded samples the encoding task will generate a notification "saying": samples encoded!

4 - Jamtaba is doing 2 things when receive a "samples encoded" notification: 1) send these encoded audio data to ninjam server and 2) send the same audio data to the activated JamRecorders.

So, at moment the audio is recorded after encoding, and the encoding is done after gain + pan law process. At moment recording is post fader and post encoding.

If I understand correctly @pljones is suggesting change recording to be pre-fader to keep the audio raw as possible.

why Jamtaba is sending the gain processed audio? In the current Jamtaba design we have gain process and encoding very coupled. The local audio is processed with gain + boost, encoded and sended/recorded. I choosed this approach to avoid the common problem of "very low level in xmited audio". Sending the raw audio (not applying gain + boost) If a musician rised your local fader and activate boost to compensante a low gain instrument (acoustic guitar, not very good mic, etc, etc..) nobody will hear this input level compensation in the server. So, the solution (used in other ninjam clients) was a second fader to control the xmited level. We know very well this solution don't solve nothing, this is not a solution, this is just another problem, specially for new users.

About send data to ninjam server and recording I choosed the current scheme (apply gains, encode and finally send audio to server and recorders) to avoid encoding twice (encode raw audio to record and encode again (after apply gain) to send/xmit the audio). The ogg vorbis decoders are fast, but the encoders are a big problem. Please try create some input chanels, feed with stereo data and check your processor usage. The ogg encoders are real bottlenecks, so we need be carefull about performance when the topic is "encoding".

---

Sumarizing, I can see 3 possibilities: 1 - Create a second background encoding task working with the raw audio. Only the JamRecorders will be interested in these encoded data. The JamRecorder will be not changed and keep receiving encoded data.

2 - Send the raw data (pre-fader) to JamRecorders, each JamRecorder can encode the audio in your own background task.

3 - Change the current scheme to do a pre-fader encoding. This is possibly the easy solution to implement, but has the big problem (xmit levels) to users. The raw audio will be recorded and sended to ninjam servers.

Honestly, I can't see any good solution at moment. The less bad solution at moment is 2, and is less bad because because 2 encodings are necessary. This can be very bad for 2 stereo input channels.

[jonjamcam]

So, at moment the audio is recorded after encoding, and the encoding is done after gain + pan law process.

Thx for the info @elieserdejesus. I had it backwards I stand corrected.

Honestly, I can't see any good solution at moment.

I agree. in my case I don't have a fast machine, so adding more stress to CPU will make Jamtaba unusable for me. I think the current desing is efficient enough. I use Jamtaba regularly with very good results.

[pljones]

This is what I was suggesting:

2 - Send the raw data (pre-fader) to JamRecorders, each JamRecorder can encode the audio in your own background task.

If (and it's definitely an "if" for me) the JamRecorder needs to encode the audio, it can (in its background task). It may be preferable to store the data uncompressed. The recorder API would then need "raw" and "ogg" calls, of course.

[jonjamcam]

It may be preferable to store the data uncompressed

I would agree on this one for a third choice in the menu; I mean to have the actual rpp, and clipsort as they are now and add a third option to store uncompressed WAV data recorded pre-fader.

[pljones]

That raises an interesting point.

Currently recorders do not have their own settings.

RPP recorder can happily use both ogg and wav files at the same time (for different parts of the project). You could choose either format for local. You could choose to have the remote oggs decoded into single wav files per track or kept as they are now.

Those settings might not make sense for the clipsort.log recorder (I've not checked -- only assumed it needs ogg files; Reaper might be just as happy with local wav files).

EDIT I've now checked and Reaper can use WAV files in clipsort.log. /EDIT

Similarly, there could be a "record what I hear" global option -- or it could be per-recorder. ("record what I hear" for remote audio being after decoding and the remote channel fader processing.)

[jonjamcam]

RPP recorder can happily use both ogg and wav files at the same time (for different parts of the project). You could choose either format for local

that sounds like an interesting implementation if the WAV file is recorded before it's encoded. @pljones Can you code this?

You could choose to have the remote oggs decoded into single wav files per track or kept as they are now.

I can't see why you'd want to do this. Remember there's no more quality you can extract from a lossy compressed file. You'd get the exact same quality but ten times the size of the file.

EDIT: Just to clarify@pljones: I can understand that you need to use WAV files instead of ogg files in your personal mixes. When you import the clipsort file Reaper always asks if you want to convert the ogg files to WAV. This is why I think it's not necessary to have this feature in Jamtaba. I see it as a waste of HDD space.

My point is that we need to develop features that benefit most of the community, not focus only on what we personally need. I've proposed many features that I personally need, but when I do this I try to have a wider scope thinking always what my last 5 years in ninjam have told me is missing for everyone else.

[pljones]

I can't see why you'd want to do this..

Entirely down to ease of use. Not everyone know what OGG files are (really, I've been surprised). Outputting WAV files is likely to make the data more accessible to a greater number of users, particularly if not just held as a series of interval length chunks. (Reaper will quite happily import and merge them into a WAV itself, of course -- this is for non-Reaper users.)

[pljones]

Hi,

I may get some time this year (!) to look at this (2016 got busy and it's stayed busy since...). Can I get confirmation of whether anything significant has changed in terms of signal flow? @elieserdejesus

Thanks,

-- Peter

[elieserdejesus]

Can I get confirmation of whether anything significant has changed in terms of signal flow?

No changes in the signal flow.