bit perfect recording

I noticed that:

  • Audacity records only at 16 bit of sample depth with Windows Direct Sound and MME drivers,
    so I can’t record anything @24 bit with these drivers.

  • Audacity with ASIO driver is able to address only the first input listed by the driver, so
    I can’t address the digital input of my boards (the digital inputs are listed/numbered always
    after the analog inputs).

  • Audacity compilation for ASIO support is a nightmare: too many warning/error notification
    in compiling/linking the audacity project to understand if I get a “true” functional copy
    of Audacity with ASIO support. When I obtain an exe file from the compilation of Audacity with
    ASIO support, it seems to be fully functional, but it is slower than the precompiled version and,
    as noted before, there is always the problem of addressing the right ASIO input.

  • Audacity with WASAPI seems the only way to record something at 24 bit of sample depth.
    The problem is that if you try to record something, you get periodic difference of samples.
    The errors are always the same errors, so the output files from different recording are equal
    each other, but different from the source for 10% of samples.

I tried with many interfaces (Terratec, M-Audio, Musiland, hiFace, E-MU, RME, Asus, etc.),
many different PCs and many Windows versions.

If I playback a WAV file with a (tested) “bit perfect” source and I record the S/PDIF out
of the source with Audacity by the S/PDIF input of any audio interface (deleted the
starting/ending "0"s in the recorded tracks) I get always a 10% of different samples
from the source, whereas the output files are always the same with all the same errors,
if I try many times the same experiment. It seems to be a code bug in the sw about
writing/reading data from hardware or buffers.

If I try the same configurations with Reaper or WaveShop I get always a bit perfect
output wav file (excluding some "0"s in excess at the start/end of the output file).

Is it possible that nobody tests periodically if there are hardware communication
problems in recording with new versions of Audacity?

Is there the possibility that someone can look into the code of Audacity to reduce
warning/errors outputted by the MS Visual Studio compiler?

Is there any chance that someone can fix the recording section of Audacity?

Thanks for any help,

gcompari

Correct. As it says on our website:
Record at 24-bit depth on Windows (using Windows WASAPI or Windows DirectSound host), Mac OS X or Linux (using ALSA or JACK host).

Audacity, as shipped, does not support ASIO (see: FAQ:About Audacity - Audacity Manual)
We provide some information about how ASIO may be added (for personal use), but it is not a feature of the official release, so technical support is limited.

So why not use Reaper or WaveShop if they work for you?

With close to half a million lines of code, it is inevitable that there will be compiler warnings, particularly as we have developers on different OS platforms. Compiler warning do get fixed on an ongoing basis (I fixed 3 compiler warning yesterday), but such warnings do not necessarily ‘need’ to be fixed. A ‘warning’ is not an ‘error’, and does not necessarily mean that there is anything wrong. The compiler is just alerting the developer to the possibility of there being a problem.

There are many reasons why you may not be getting bit-perfect recording, most of which have nothing to do with Audacity. For what it’s worth, I’m getting bit-perfect recording when using Jack on Linux.

Which 10%? If it’s the LSBs then it probably caused by dither or resampling, in which case it is a settings problems, but you’ve told us nothing about that.

The site is correct for Audacity 2.1.3 (the current release). If gcompari compiled an older version of Audacity then DirectSound will still only record 16-bit.

Have you tried recording all the channels, or all the channels as far as the ones you want, then closing the redundant tracks?

Audacity can’t yet pick and choose for example inputs 5 and 6 separately. That would be a “feature request”, if you want to vote for that.


Gale

Sorry, if I’m new to this forum so I don’t know if I’m using the correct whay to reply.

So why not use Reaper or WaveShop if they work for you?

Because Reaper isn’t free and WaveShop is a very basic program, and (most important) because I like Audacity: I find it very powerful and very simple to use.

Correct. As it says on our website

Probably it is the time to eliminate these limitations: you can edit a 24 bit file w/o problems, but you can’t record anything w/o errors…

Audacity, as shipped, does not support ASIO (see: > http://manual.audacityteam.org/man/faq> _ … .html#asio)
We provide some information about how ASIO may be added (for personal use), but it is not a feature of the official release, so technical support is limited.

These informations produce an audacity.exe that can address only the first two channel listed by the ASIO driver, so the S/PDIF channels are unusable to record something
by digital inputs, because normally they are enumerated after the main analog inputs in all audio interfaces.

With close to half a million lines of code, it is inevitable that there will be compiler warnings, particularly as we have developers on different OS platforms.
Compiler warning do get fixed on an ongoing basis (I fixed 3 compiler warning yesterday), but such warnings do not necessarily ‘need’ to be fixed. A ‘warning’ is
not an ‘error’, and does not necessarily mean that there is anything wrong. The compiler is just alerting the developer to the possibility of there being a problem.

I worked in the past for twenty years on developing software in a team: we worked with all levels of the compiler warnings enabled and each component of the team never released
a module with a single warning: when a warning appears this means that the compiler may misunderstand something, so we “cast” or we change little things to resolve
a potential problem. Often a warning revealed a real error that the compiler can’t find. In this way the warnings are very useful because indicate a poor write code
that can produce unexpected results or show a “semantic” error. If you compile Audacity and you get 546 warnings, it is very difficult to understand if you make something
wrong…

There are many reasons why you may not be getting bit-perfect recording, most of which have nothing to do with Audacity. For what it’s worth, I’m getting bit-perfect
recording when using Jack on Linux.

As I wrote before, I get bit perfect recording with Windows, but with non-free software or very basic software: Audacity is a great piece of software, but it is incredible
that can’t record anything w/o errors if I exceed the CD quality! I’m not interested on Linux, so I post my question in the Audacity/Windows forum.

Which 10%? If it’s the LSBs then it probably caused by dither or resampling, in which case it is a settings problems, but you’ve told us nothing about that.

When I record @24bit with Audacity, I get 10 megabyte of identical samples and 1 megabyte of bad samples, and so on. If the problem is the dithering (that is disabled in my configuration), all samples would be different. Why don’t you try to record a stream by a digital input and you compare the source file and the output file? If you got bit perfect in Linux, you can use the same hardware in Windows. I hope the windows driver of your hw aren’t so bad… Foobar with WASAPI support is a bit perfect player, so you can check yourself
Audacity for Windows.
The less expensive configuration that I know to get bit perfect recording in Windows is: source => Musiland Monitor 01 USD (optical and coax digital outputs) + Foobar2000 + WASAPI
component + S/PDIF optical cable; recording equip. => Terratec Aureon xFire 8.0 HD (USB) + WaveShop + 100ms buffer setup. You will get bit perfect recording at
44.1/16, 44.1/24, 48/16, 48/24, 88.2/24, 96/24. At 176.4/24 and 192/24 there is a driver problem, so you can’t get bit perfect recording. Please note that
88.2/24 (and 176.4/24) are not officially supported by the Aureon, but they work.

gcompari

The site is correct for Audacity 2.1.3 (the current release). If gcompari compiled an older version of Audacity then DirectSound will still only record 16-bit.

I compiled the 2.1.2 version.

Have you tried recording all the channels, or all the channels as far as the ones you want, then closing the redundant tracks?

I can’t see any other channel than 1 and 2 (with all board that I tried, included a RME BabyFace Pro that I bought to be sure that the problem wasn’t in a bugged driver or a cheap harware).

Audacity can’t yet pick and choose for example inputs 5 and 6 separately. That would be a “feature request”, if you want to vote for that.

Probably I need to vote as a “feature request” the list function of all channel of an ASIO driver…

gcompari

Looks fine. Your in-line quoting is easy to follow.

Rather an overstatement. I’m not seeing the problem you report, so although you may have identified a bug, and it may be a bug in Audacity, it is certainly not a universal problem as your comment implies.

As Gale suggested, have you tried increasing the number of recording channels? On the Audacity side you do that by selecting the number of channels in the device toolbar. I would love to see “channel mapping” in Audacity so that any input channel(s) can be recorded in any order of tracks, but no-one has written that yet so it remains a “feature request” until someone writes the code. Please note that Audacity is not a company with employed developers, it is a community project developed and supported by enthusiasts.

Excellent. Perhaps you would be interested in contributing to the further development of Audacity: Redirecting to: https://audacity.gitbook.io/dev

I agree. Perhaps you could help reduce the number of warnings. I’ve eliminated 3 from Linux this week, so if they are among the warnings that you get, there’s only 543 left to go :wink:

Done that. Output == Input on my machine. I don’t use Windows.

ASIO support is unlikely to happen in release builds for the reasons given: Missing features - Audacity Support

Note that we have a policy not to fix compiler warnings in third-party libraries (those in the lib-src folder in the source code).

The policy is to fix compiler errors in our own code, when time permits.


Gale

We don’t count up votes for ASIO support because it is something we can’t legally provide in a public release. But you’re welcome to vote for (or help us develop) channel mapping features.


Gale

steve wrote: Rather an overstatement. I’m not seeing the problem you report, so although you may have identified a bug, and it may be a bug in Audacity, it is certainly not a universal problem as your comment implies.

Sorry, but do you tried to get bit perfect recording only with Linux?

Try to get it with Windows and tell me…

You are right, probably my comment isn’t universal: perhaps there are 2.09% of people using a PC that can get bit perfect recording like you:

I’m talking about the 91,68% of PC users (=>Windows)…

If you was ever able to get perfect recording with Windows, may you describe your configuration?

I’m interested in “bit perfect” recording of these formats: 44.1/16, 44.1/24, 48/16, 48/24, 88.2/24, 94/24, 176.4/24 and 192/24.

I tried Audacity on 7 different PCs (desktop and laptop), mostly running Windows 7 Pro SP1 32 & 64 (I’m not very interested in Win 8, 8.1, 10) and with these interfaces:

  • Aphex IN2 (USB)
  • Asus Xonar D2X (PCIe)
  • E-MU 0404 USB (96/24 max.) (2 different devices) (USB)
  • ICON Cube 4 Nano (USB)
  • M-Audio Transit USB (96/24 max.) (USB)
  • M-Audio Delta Audiophile 192 (PCI)
  • RME BabyFace Pro (USB)
  • RME DigiFace (USB)
  • Speeddragon UAU10A (USB)
  • Terratec Aureon xFire 8.0 HD (USB) (2 different devices)

and I never got a bit perfect output file with Audacity, only with other DAW software but they are expensive (and very difficult to use) or very “basic” (very limited functionality).

gcompari

My choice of operating system is not up for discussion.

As a practical suggestion, you could use Wavosaur for recording. It has ASIO support. It’s not open source, but it is free. If you prefer to edit in Audacity, you can save your recording from Wavosaur, then import them into Audacity for editing.

The same for me: this is the reason I posted the problem in the Windows Audacity Forum…

Wavosaur works with ASIO only for output channels: no records are possible with an ASIO input channel. I have already analyzed and tried it: it doesn’t work.

I think Audacity performs 3 categories of functions: a) record b) edit c) signal generation. I think the (a) function doesn’t work correctly: perhaps it’s better to solve the problem instead of inviting people to use other programs.

In the meantime I’m using WaveShop (free) and Reaper (that supports WASAPI, DirectSound and ASIO, but it isn’t free).

I’m working on a project (my PHD thesis) with a minimal setup in terms of costs and components to get the goal (it’s a low cost DAW to test Personal Audio devices as FiiO, iBasso, Centrance, HRT, Onkyo, Oppo, Denon, Sony, etc., DACs/HeadAmps/Mobile Players), so I need a free DAW software to record, edit and generate audio files.
The use of WaveShop is dangerous because the user must remember to set all levels and options in the Windows mixer to avoid any audio signal alteration/elaboration (WaveShop don’t use WASAPI or ASIO that are the only drivers that bypass the Windows Kernel Mixer).
Reaper isn’t free and it isn’t simple to use as Audacity.
Either WaveShop and Reaper are “bit perfect”.
Audacity is “bit perfect” in editing audio files, but from the 2.x version it isn’t “bit perfect” anymore in recording audio signals: you get very long portions of the output file w/o any difference of samples and some little parts of the output file with wrong samples: I didn’t check if the errors are exactly periodic, but they seem periodic-like.
You can repeat the record any time you want and you get always exactly the same errors (with the same record audio interface).
The errors are consistent only with identical (or very similar) record audio boars: RME DigiFace and RME BabyFace boards get always the same (identical) output files. But the Tearratec Aureon xFire 8.0 HD and M-Audio Delta 192 Audiophile and RME DigiFace/BafyFace Pro interfaces (all “bit perfect” audio boards) produce different audio files (after deleting header and the “00” sample bytes at the beginning and at the ending of files), so the problem seems to be driver communication interface related.

Regards,

gcompari

Thank you for the sample WAV files. I can now see what the problem is.

In this screenshot, the upper track is your source file, the middle track is your recorded version, and the bottom track is the difference between the two which I have then amplified by 36 dB so as to make the difference visible.

To make the third track, the other two tracks must be carefully aligned, then mix a copy of track 1 with an inverted copy of track 2.
tracks004.png
The interesting thing to note is that the first track (the source track) shows evidence of clipping (the red vertical lines), and close examination shows that the “differences” (the blips in track 3) correspond to the clipped regions in track 1.

Looking more closely we can see that the difference comes in gradually a few milliseconds before the clipping, then fades away to zero a few milliseconds after the clipping.
tracks005.png
Using the “Sample Data Export” tool, we can see that the audio between the blips in the third track is absolute silence, indicating that other than around the regions of clipping in the source track, the copy is indeed “bit perfect”.

In fact, the issue of non-exact copying does not only happen at regions of clipped samples. It occurs whenever the peak level in either track gets within about -0.1 dB of full scale. At this times, the recorded track shows a small amount of negative gain has been progressively applied. Somewhere within your signal chain, a real-time look-ahead limiter is being applied. I can’t tell if this is built into your hardware, or the software drivers, but I can say that it’s not written into Audacity’s code because Audacity does not do real-time processing.

The characteristics of the limiter can be seen quite clearly, and the effect is certainly intentional. The look-ahead time is about 5 ms, and both channels are linked so that identical gain is applied to both channels (so as to avoid unpleasant effects in the stereo balance).

As for why this didn’t happen with your other software, I don’t know for sure. Perhaps you used different source material that wasn’t clipped. Perhaps you were using different drivers. My ‘guess’ would be that it occurs during a conversion from floating point to integer format, but it could be quite tricky to pinpoint. Whatever the exact cause, it is clearly intentional, and it only occurs when the peak level of the source material is clipped or dangerously high.

As requested by Steve I’m posting the steps
to reproduce the “bit perfect” problem: sorry for the delay.

  1. Download the file:
    http://www.lindberg.no/hires/test/2L-077-stereo-96kHz_21.flac

  2. Convert the downloaded flac file to wav, for example by Foobar and/or the FLAC engine:
    http://flacfrontend.sourceforge.net/
    http://downloads.xiph.org/releases/flac/flac-1.3.2-win.zip
    and save it as source96.wav.

  3. Edit the file with Audacity:

  • Normalize (very important: w/o this action, the problem sometimes doesn’t happen)
    the track to “0dB” with Effect => Amplify
  • Insert (Generate) 1 second of silence at the beginning
    and 1 second of silence at the end (this grants the time for a correct
    sync between the S/PDIF source port and the S/PDIF recording port and the
    time for emptying the sw/driver buffers).
  1. Export the file:
    File => Export audio => Other uncompressed files => WAV Microsoft => Signed 24-bit PCM: save “clearing” all metadata
    http://www.globalcomputing.it/audio/OutputSettings.png
    (here there is always the aiff=>wav extension naming problem).
    You will obtain a file like this:
    http://www.globalcomputing.it/audio/source96.wav

  2. To obtain the “clean” version of the source96.wav, open the the file with this free hex editor (last version):
    https://www.hhdsoftware.com/free-hex-editor

  3. Find the first hex “ff” byte in the file:
    CTRL+F + “Search Down”
    http://www.globalcomputing.it/audio/FirstByte1.png
    so you are in this situation:
    http://www.globalcomputing.it/audio/FirstByte2.png

  4. Select all bytes from the first not “00” byte to the beginning of the file:
    with CTRL+SHIFT+HOME select all the previous portion of the file and press DEL to delete it.
    http://www.globalcomputing.it/audio/FirstByte3.png

  5. Delete the remaining “00” byte before the first non zero byte.
    http://www.globalcomputing.it/audio/FirstByte4.png
    Now here you are:
    http://www.globalcomputing.it/audio/FirstByte5.png

  6. Go to the end of the file with CTRL+END.

  7. Search for the end of the source file:
    Search “Up” for the last “FF” byte with CTRL+F and “Search Up”:
    http://www.globalcomputing.it/audio/LastByte1.png

  8. Go to the first “00” byte of the region with all “00” bytes at end of the wav file (you found it after the “FF” byte).
    http://www.globalcomputing.it/audio/LastByte2.png

  9. With CTRL+SHIFT+END select all “00” bytes to the end of the file
    and delete them with DEL.
    http://www.globalcomputing.it/audio/LastByte3.png

  10. With CTRL+END go to the end of the file. You are here:
    http://www.globalcomputing.it/audio/LastByte4.png

  11. Save the modified file as “source96.bin”. You will get:
    http://www.globalcomputing.it/audio/source96.bin
    Exit from the hex editor w/o saving the project

  12. Use a “bit perfect source”: I usually use the Musiland Monitor USD 01
    http://www.musiland.com.cn/index.php/Product/show/id/143
    because is a very low cost “bit perfect” device with either optical and
    coaxial digital S/PDIF output. I’m using the bundled drivers:
    http://www.globalcomputing.it/audio/Musiland_Monitor_01_USD.png

  13. Use the last version of Foobar 2000 (1.3.15) http://www.foobar2000.org/download
    with the last version of the WASAPI component (3.2.3) http://www.foobar2000.org/components/view/foo_out_wasapi

  14. Use a “bit perfect” recording interface. I used for this test:

  1. Connect you audio recording board (in my case the RME BabyFace Pro).

  2. Start Audacity

  3. Select WASPI as “Audio System”

  4. Select your digital S/PDIF input (here there is a problem: you can see in the input selection all
    audio endpoint (input and output!) and the edit list is so short you can’t understand what you are selecting).
    http://www.globalcomputing.it/audio/Audacity_Settings_03.png
    You will be here:
    http://www.globalcomputing.it/audio/Audacity_Settings_01.png

  5. Set the default sample rate and sample depth of Audacity, and disable all dithering:
    http://www.globalcomputing.it/audio/Audacity_Settings_02.png

  6. Set the correct sample rate and sync mode of your recording interface:
    http://www.globalcomputing.it/audio/RME_BabyFaceProSetup.png
    remember to restart Audacity or use “Transport” => “Rescan audio devices”

  7. Connect the S/PDIF output of your bit perfect source to the S/PDIF input of your recording interface.

  8. Set your bit perfect source parameters:
    http://www.globalcomputing.it/audio/FoobarSetup.png

  9. Restart Audacity to load the new setup and the new recording board driver status
    (this is another problem: some settings don’t work if you don’t restart Audacity).

  10. Start Play with Foobar w/o recording: this enable the correct sync between the S/PDIF in/out ports.

  11. Stop Foobar

  12. Start recording with Audacity

  13. Start Foobar

  14. Leave Foobar to stop automatically after the play

  15. Wait 1 or 2 seconds to leave the buffers go empty.

  16. Stop Audacity recording.

  17. Export the file:
    File => Export audio => Other uncompressed files => WAV Microsoft => Signed 24-bit PCM: save “clearing” all metadata
    http://www.globalcomputing.it/audio/OutputSettings.png (file name: target96.wav)
    (here there is always the aiff=>wav extension naming problem).
    You will obtain a file like this:
    http://www.globalcomputing.it/audio/target96.wav

  18. Repeat steps 6) to 14) to clean the target96.wav file and save it as target96.bin.
    You will get a file like this:
    http://www.globalcomputing.it/audio/target96.bin

  19. Open a DOS session in your working folder and do:
    “FC /B source96.bin target96.bin >error_list.txt”
    You will get an output file like this:
    http://www.globalcomputing.it/audio/error_list.txt
    As you can see, you may get 5.370 different bytes from 116.444.319 total bytes of the source and target “.bin” files.

I get exactly the same errors using a different PCs (HP EliteBook 8470p
and Asus UX32LA for example, and different Windows versions (Windows 7 Pro 64 bit
English version and Windows 7 Pro 32 bit Italian version).

Using Reaper (with WASAPI, or ASIO, or DirectSuond drivers)or WaveShop (with DirectSound drivers) with the same hardware/software
setup, the error_list.txt file becomes an empty file!

gcompari

Except they are now different steps and different files. Why is that?

Is that not the point of Steve’s explanation of what is happening?

Why it is necessary to use the Musiland device rather than play from Foobar to Babyface S/PDIF in and record from Babyface S/PDIF out?

Why do you enable “Eq for record” in Babyface settings? That won’t give you a flat recording.


Gale

Absolutely.
If the maximum sample value is 0 dB, then the inter-sample peak will be a little over 0 dB, which is thus driving into clipping. Some part of gcompari’s system is protecting against over zero dB by limiting sample values to fractionally below 0 dB, which is no bad thing because “look-ahead limiting” is acoustically far less bad than clipping.

The source audio that was originally posted shows visible (but still virtually inaudible) signs of clipping damage, and I would be much more concerned about that than a totally inaudible amount of limiting, which is only present at all because the source level is dangerously high.

You are right the problem happens only with “normalized” to 0 dBfs tracks. A normalized to 0 dBFs track isn’t dangerous and isn’t rare: this kind of track maximize the S/R, minimizes the quantization error (THD) and grants the ADC/DAC to use the maximum linearity region of conversion (THD/IMD).

Moreover hw/sw “limiting” is a nonsense for a digital input, because it can’t receive any more bits than the digital format states. An hw/sw limiter is useful only before the ADC: a 96/24 digital signal can’t exceed the 24 bit.
Nor the hw nor the drivers “intentionally” limit anything: using the same hw/sw configuration and changing only Audacity with Reaper or WaveShop you can get a bit perfect recording of the same source track.
If Audacity “does not do real-time processing”, what happens for PortAudio library?

With identical configuration (same O.S., same PC, same drivers, same audio hw, same track), but with other DAW software, you get always a bit perfect recording: you may try Reaper (http://www.reaper.fm/) and WaveShop (http://waveshop.sourceforge.net/). But other softwares aren’t free, or aren’t simple to use as Audacity, or aren’t poweful as Audacity and I think Audacity may reach the “bit perfect” attribute if someone try to investigate the problem.
Is very disappointing to get good hardware and lose precious bits in software w/o any reason…

gcompari

Because the original source track was copyrighted. Originally I posted my message in the Audacity bug reporting section and not in public domain.

Because the free downlodable track that I found for the example in the public domain wasn’t normalized to 0 dBFs: we work always with normalized tracks to maximize audio performances.

Because I’m working about a DAW for personal audio devices testing, as mobile DACs/Headamps: is too simple to test in loopback the S/PDIF in/out of the same interface: the clock is the same, the input outputs are from the same manufacturer, etc. etc.

It doesn’t change the result: the EQ was disabled from the “RME TotalMix FX module”. You can try with and w/o this checkbox enabled and you can verify that the recorded track doesn’t change. I unchecked it and replayed the full process and I got an identical error_list.txt file.

gcompari

No submitted track was clipped: only 0 dBFs normalized.

gcompari

If you amplify by anything but a power of 2 with an integer format, there has to be rounding, thus Normalizing adds distortion (albeit an insignificant amount). Unless you are working from higher than 24 bit masters, the is nothing to gain by normalizing, not even inaudible but theoretical gains.

You may also find it informative to look up “true peak”.

Regardless of further discussion, the behaviour is clearly intentional, and clearly not in the Audacity code (otherwise it would also happen on Linux), and is not audibly damaging, so as I said, I would not be concerned about “bit perfection”.

I would however be concerned about this - which is one of your source tracks:

I understand that Audacity shows clipping when touching 0 dB. So if gcompari’s files are normalized to 0 dB, they will show “clipping” in Audacity.

This makes a sensible option for actual users though. :wink:

In the way you are using Reaper and Waveshop, do they capture unmodified 24-bit samples from WASAPI Exclusive Mode, thus bypassing Windows upsampling to 32-bit float?


Gale