bit perfect recording

Audacity 3 Help Forum Windows
21

No two ways about it - the right channel. It is very obviously clipped.

22

To avoid rounding problems I use a project with 96kHz sample rate and 24 bit sample depth: if you get a 96/24 digital input stream, Audacity must only transfer the 24 bit sample in its buffer: no need to round anything.
And, in effect, for the 99,99% of cases the aren’t errors. To normalize the sample tracks I submitted, I used Adacity => Effect => Amplify and I accepted the “Amplification (dB)” factor proposed automatically by Audacity itself.
Even if the Amplify effect would be bugged, the problem isn’t in the source track: the problem is in the recorded track!
On the S/PDIF input of the recording card there will be always a correct 24 bit configuration of each sample and Audacity has to acquire and transfer in its buffers only these bit sequences w/o any rounding and other elaborations.
If you get a recorded (by digital in/out) track that is different from the source track there is something that doesn’t work: I never normalized the recorded track, so all the problem that you reported about normalization are inexistent in the output track.

In the 69th Convention of AES (12/15 May 1981), Louis D. Fielder (Ampex Corp.) stated “A dynamic range of 118 dB is determined necessary for subjective noise free reproduction od music in dithered digital audio recorder”
and “Electronically amplified music may create a larger requirement because of the higher sound level possibile” (near 6 dB more: total 124dB)
so you can’t lose no one bit from the 24 available when you play a track… For this reason in the audio recording studios they record at 32 bit.


Probably it is intentional for Audacity: other DAW softwares (in the identical hw/sw configuration) work right: no errors and you can check by yourself, if you wish.
“Bit perfect” means that you can edit and save an audio file haw many times you wish w/o lose a single original bit.
With a “bit perfect” chain you are sure that storing and transmitting a stream trough many devices you don’t lose anything.
“Bit perfect” means that all bucks you spend for an expensive audio interface are not wasted by software or digital communication errors.
In the digital domain there are no reason to lose bit somewhere…
Leave the problems in the analog or ADC/DAC sections of the hardware where the problems are real.

When I asked R.M.E. (http://www.rme-audio.com) about the “bit perfect” attribute to choose between theirs products, they answer me:

Hello,
There are no differences here whatsoever.
No RME device is in any way better or worse for SPDIF transfer because of the absence or presence of analog circuitry.
The theoretical jitter values also have no influence here at all.
Anything but absolutely bit perfect would be a defective or unusable device…

I can’t understand as you consider Audacity for Windows and Audacity for Linux the same program: how many are the Audacity source code lines that are O.S. dependent? And in the libraries used? Do you think that the source code of Audacity is been compiled exactly in the same way in Linux as in Windows environment?
How many warnings do you get compiling Audacity in Linux? Always the same 546 warnings that we get in Windows?

The low level interaction between Audacity (+ the associated libraries) and (so different) operating systems probably count for a 10% of the total application source code: so you decided the there isn’t any problem in the audacity.exe Windows program (and the related DLLs) because you don’t get the same error in Linux?

There is someone that can test the reported problem in Windows?

Regards,

gcompari

23

With WaveShop I must use Direct Sound drivers: so I need to set in the Windows Audio Control Panel the correct sample rate and sample depth to avoid Windows Kernel Mixer resampling.
Then I set the 96/24 project track in the WaveShop options and I start to record.

With Reaper I can use WASAPI, so I set in the audio preferences the correct sample rate and sample depth and I start recording.

If you think would be useful, I can post my step by step procedure as I posted the procedure of recording with Audacity, so you can valuate the results and you can try by yourself the entire procedure.

gcompari

24

Yes, and you stated many posts back that in this respect Audacity is “bit perfect”.

The “problem” that you have demonstrated is that if pass clipped audio through your set-up, the data around the clipped audio is not bit perfect. The solution seems blindingly obvious to me - if you want a very high quality recording, don’t use clipped source material.

This is a non-problem and further discussion is a waste of all our time. If you prefer bit perfect clipping and you can achieve that with Reaper or some other software, then by all means please feel free to use other software. Audacity is offered free for use without guarantee. I am satisfied that your “problem” arises from flawed testing rather than an Audacity bug but that you are unwilling to listen to reason, so as far as I’m concerned this matter is now closed.

FWIW, I do find it interesting that this is happening, and I am curious why / where it is happening, but I’m not going to be drawn into a pointless argument.

25

There is no interface around that can produce 118 dB dynamic range. And certainly not 124 dB. Besides, our ears wouldn’t be able to stand 124 dB SPL, even if we could start from a zero dB noise background…

Ampex was still into analog tape when this was committed to paper? :laughing:

26

As previously explained the audio is always captured in Audacity at 32-bit float. The 24-bit sample is always manipulated in this way. And according to http://www.globalcomputing.it/audio/Audacity_Settings_02.png you have Default Sample Format set to 24-bit, so every sample is then downconverted back to 24-bit.

I don’t know that this is anything to do with the cause of the “problem” but I’m not clear from your answer about how you have Reaper and Waveshop set to handle this. If the recorded track data is 24-bit, has it avoided conversion to and from 32-bit float?

If you want to test, you can isolate whether Audacity’s WASAPI support is something to do with this.

Use the current Audacity 2.1.3 to record 24-bit under DirectSound.

Use WDM-KS in Audacity 2.0.4: https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/audacity/audacity-win-2.0.4.zip. As far as I can tell from lib-src\portaudio-v19\src\hostapi\wdmks\pa_win_wdmks.c, our currently abandoned WDM-KS support included 24-bit recording.


Gale

27

Only to remain into the region of low cost interfaces…

They recorded the San Jose Symphony Orchestra at The Automatt Recording Studios.
Noise levels present during quiet periods in a classical music performance measured at The Automatt Recording Studios. :slight_smile:

28

None of my source tracks are “clipped”: only normalized with Audacity => Effects => Amplify => 0 dB

gcompari

29

Here a source square wave at -0.131dB surely not clipped

Here a source square wave at -0.132dB surely not clipped

Here the recorded square wave at -0.131dB recorded by Audacity

Here the recorded square wave at -0.132dB recorded by Audacity

Here the source square wave at -0.131dB “cleaned”
http://www.globalcomputing.it/audio/source96-0.131dB.bin

Here the source square wave at -0.132dB “cleaned”
http://www.globalcomputing.it/audio/source96-0.132dB.bin

Here the recorded square wave at -0.131dB “cleaned”
http://www.globalcomputing.it/audio/target96-0.131dB.bin

Here the recorded square wave at -0.132dB “cleaned”
http://www.globalcomputing.it/audio/target96-0.132dB.bin

Here the difference at -0.131dB => 3.843.318 errors
http://www.globalcomputing.it/audio/err_list_-0.131dB.txt

Here the difference at -0.132dB => 0 errors
http://www.globalcomputing.it/audio/err_list_-0.132dB.txt

Any track less or equal 0.132dB => no errors

Any Track = or > -0.131dB => millions of errors

Here a source square wave at 0dB surely not clipped: generated by Audacity => Generate => Tone => Square Wave => 1

Here the recorded square wave at 0 dB recorded by Audacity

Here the source square wave at 0dB “cleaned”
http://www.globalcomputing.it/audio/source96.bin

Here the recorded square wave at 0dB “cleaned”
http://www.globalcomputing.it/audio/target96.bin

Here the difference at 0dB 17.279.606 errors: practically all bytes
http://www.globalcomputing.it/audio/err_list_0dB.txt


Audacity Recording is bit perfect only for tracks <= -0.132dB
Audacity Recording isn’t bit perfect for tracks exceeding (>= ) -0.131dB

No errors at all, recording any square wave (also at 0dB) with Reaper
No errors at all, recording any square wave (also at 0dB) with WaveShop
with:

  • Same PC
  • Same audio interfaces
  • Same Operating System
  • Same drivers
  • Same source tracks

Tried with 4 different recording interfaces RME BAbyFace Pro, RME DigiFace USB, Terratec Aureon xFire 8.0 HD, M-Audio Delta Audiophile 192
Tried optical and coaxial S/PDIF path

It seems that when there are samples with more than the 6 most significant bit high of the 24 total Audacity loses the 18 remaining bits.

gcompari

30

I you try to edit any 24 bit track with Audacity (for example adding or removing silence in the track) you never get a 24 bit different track in the remaining samples: so the conversions are always “bit perfect”.

I don’t know the “internals” of WaveShop and Reaper: I only know they work.

Audacity can record at 24 bit only with WASAPI: DirectSound are supported only at 16 bit. If you record at 24 bit with DS/MME drivers you get the last significant 8 bit filled with random values
ASIO is a nightmare with Audacity, so it is practically impossible to test anything (I described these problems at the beginning of this thread: in detail, I can’t address digital inputs with ASIO. They are never the first listed channels and Audacity with ASIO can address only the first 2 channels)
WDM-KS doesn’t work with my bit perfect interfaces. I haven’t found any recent audio interface that works with WDM-KS.

gcompari

31

Not if you process the audio with a filter.

The statement about DirectSound appears to be false, from the experiments that others have made:

Comparison Audacity 2.1.2 with 2.1.3_CKZ.

Please provide the evidence that DirectSound does not record genuine 24-bit samples using 2.1.3, (NOT 2.1.2).

You never answered what happened if you tried to increase the number of recording channels above 2 in Audacity. You could attach Help > Audio Device Info… from top right of Audacity so we see what devices Audacity sees. Stop all audio transport before accessing that item.

How does this compare with WaveShop and Reaper? Do they see ASIO digital inputs?


Gale

32

To check “bit perfect” I don’t apply any filter: my edit is only for delete silence at the beginning and at the end of the recorded track.
Sometimes Audacity opens a 96/24 track as a 96kHz/32bit float, and after my edit, if I export the file I get a “bit perfect” copy of the original track: so the 32bit forward and back conversions are “bit perfect”.
The problem is only with recording.

You are right: with 2.1.3 it seems that I can record at 24 bit.
I read the 2.1.3 new features, but I didn’t find anything about this fact: I think is one of more significant improvement of Audacity! Why don’t you list it in new features?
From the the Steve reply to my initial post on May, 21 2017:

and Audacity 2.1.3 was already released.
This is a great news!


Sorry, but I don’t trust in Audacity with ASIO. So I have deleted it.
What I achieved:

  • my ASIO audacity.exe was very slower than the normal precompiled version
  • my ASIO Audacity that creates some problems with other drivers (if I’m playing something with Foobar, starting Audacity causes problems to Foobar playing with other interfaces)
  • my ASIO Audacity.exe creates some problems with configuration settings of the precompiled version
  • my ASIO Audacity.exe was 2.1.2, so I need to recompile all the program (a nightmare!): so I lose all the new features of Audacity 2.1.3
  • my version of the compiled libraries are much grater than the DLLs bundled with precompiled Audacity and I don’t know why.
  • I had to insert “#define PA_USE_ASIO 1” because the guide for the Audacity compilation didn’t get an Audacity with ASIO enabled: so I’m very dubious about compiling Audacity with ASIO.
    This is a pity because many audio interfaces work at full performances only with ASIO: for example Focusrite USB series (Scarlet 2i2, Scarlet 2i4, etc.: WDM drivers are only for 16 bit! ASIO for 24bit)
    Why don’t abandon the Steinberg ASIO SDK and write some code to interface ASIO directly?

WaveShop uses only DS drivers, but it is “bit perfect”.
Reaper works with ASIO and it doesn’t have any problem with ASIO drivers (it lists all interface channels) and it is “bit perfect” with Direct Sound, WASAPI and ASIO drivers (but it isn’t free at all: only a very extended free period of trial)

33

I abandoned tests with Direct Sound because I thought that the 16 bit limitation with these drivers was never removed.

The last time I checked Direct Sound was with the 2.1.2 version.

You are right: now Audacity can record @24bit with Direct Sound!

And there is an other good news: AUDACITY RECORDING IS NOW “BIT PERFECT” with Direct Sound drivers!

The problems seem to be related only to the Audacity/PortAudio WASAPI interface.
Perhaps are there some switch in the PortAudio library that can introduce a software limiter with WASAPI?

gcompari

34

It’s an omission, but not a serious one because most users won’t care. It is mentioned on Redirecting to: https://www.audacityteam.org/FAQ#features.

Some people say that the launch time before ASIO appears as a host is greatly extended, some not. If you build debug configuration, this is slower than release configuration.

I think there is a PA_ENABLE_DEBUG_OUTPUT flag which is enabled by default in the MSVC project, in both debug and release configuration. It is possible that turning that off might help.

I would expect a problem if you were using the same device. The basic idea behind ASIO is that audio applications take ownership of the ASIO device. Some devices provide a multi-client driver, but few do.

I am not sure what you mean exactly. I recommend putting a Portable Settings folder in the folder containing the ASIO-enabled Audacity. Then the settings for the ASIO-enabled Audacity will only affect that version.

There are no open source ASIO headers we know of.

You might be better to use one of the Voicemeeter products to pipe input from an ASIO device into Audacity. This will only be two channels though on Vista and later, and standard high latency, if you use non-ASIO Audacity. This is supposed to be “bit perfect”.


Gale

35

Thank you for testing. Although I don’t rate this problem as highly as you, I now assume we have identified the “issue” as being in PortAudio’s WASAPI implementation.


Gale

36

Actually there are, but it dubious whether these open source drivers infringe the Steinberg developer’s agreement.
One of our developers sent a patch to PortAudio that allows PortAudio to support ASIO with open source ASIO headers, but it was declined by PortAudio due to their concerns over licensing. (It was also declined by Juce for the same reason, though that has no relevance to Audacity)

37

I’m very astonished about it: before that, the only way to record something more than 16 bit was WASAPI, with all problems showed before.

Surely it can help: but why to enable PA_ENABLE_DEBUG_OUTPUT in the release version?

The problem happens with other interfaces: it seems that the ASIO-Audacity scan for new devices at the start up in a different way of the standard Audacity.

When I change the Audacity.exe in the “Program files\Audacity” folder with the executable with ASIO support and I revert back to the standard precompiled version, the program starts very slowly.
To go back to the normal functioning, i need to deinstall and reinstall the standard Audacity, after deleting the Program files\Audacity folder and all traces in the file system and registry of Audacity.


Is it possible to create one header directly form ASIO specifications?

If I’m right, the Voicemeeter input from ASIO physical devices is limited to 96/24.

To make Audacity support ASIO effective is fundamental to make it very popular: until the compilation of Audacity with ASIO is so difficult, less than the 1% of the users will test it.
If I try to realize a video with all passages to compile Audacity, with all the results/problems obtained, will you have time to correct it and show where are the wrong action/steps?
If someone will create an easy/secure method to compile the ASIO-Audacity executable, probably the ASIO support would be a serious feature…

38

Yes, now the “issue” is related to PortaAdio/WASAPI interface only, but WASAPI is very important:

  • low latency
  • kernel mixer bypass

gcompari

39

So please tell us what the “some problems” are exactly.

Does that still happen if you only run the ASIO build from its build folder in the Audacity source code?

Audacity is a free application run largely on a volunteer basis. Because we can’t distribute ASIO support, and given our limited resources, that means the priority of any ASIO bugs is very low.


Gale

40

There is nothing stopping you contacting the PortAudio developers mailing list with your concerns.


Gale