Hi, the title might sound a bit confusing after this but here’s my current situation: I’m in the process of merging a few sections of audio from a 16-bit flac stream into a 24-bit flac stream. Whenever I export, it all goes well and quick peak shows that is a 24-bit flac file. Now my issue is when I use this new audio file in other programs it is identifying the file as a 16/24-bit file and not just a 24-bit file which is causing issues.
What I want to do is have that 16-bit part of the stream actually be 24-bit (superfluous 0s) and have the whole stream behave as 24-bit but I cannot seem to find a way to have my exported audio behave this way (exporting as 24-bit does not solve it). Any help or advice on why this happens and what I can do to have this audio appear as a consistent 24-bit stream would be greatly appreciated.
Eac3to is identifying the file as a 16/24-bits flac file instead of a 24-bit flac file as it normally does. It becomes an issue when I perform offsets or other adjusts that I would normally script (something I can’t do as easily in Audacity). More or less, the program decides to stop reading the rest of the file when it hits a point where it goes from 16-bit to 24-bit. The program doesn’t crash it just thinks it’s done. I’ve gotten around this for now my saving the file as 32-bit float PCM and then having Eac3to convert from that to FLAC (everything should still be lossless, no dithering was done on export). After I perform those steps Eac3to correctly identifies the file as a 24-bit flac and it can be used.
I realize there is absolutely no benefit (in terms of quality) from introducing superfluous 0s to a 16-bit stream to make it 24-bit but the point was to have a consistent bit depth throughout the stream file since the rest of the stream is 24-bit.
Based on the data I got from Eac3to when it identified the audio, it seems like Audacity is trying to create a smaller file size by maintaining the 16-bit part of the stream as 16-bit instead of allowing superfluous 0s to be introduced to make the whole stream 24-bit. It reminded me of variable framerates in video files. I realize this probably sounds like a bug with Eac3to but it does make me wonder how exactly Audacity handles the export of a project that has both 16-bit and 24-bit audio when it is being told to export it as a 24-bit flac file.
Audacity uses the official FLAC encoding library. It passes the audio data to the library, then lets the encoder do its thing.
For exact details about how the FLAC encoder works you would probably be better asking the guys at Xiph: https://xiph.org/flac/
What exactly do you do in Audacity? Do you import one 16-bit FLAC, then import a 24-bit FLAC in another track, and then what?
Or do these original files contain multiple streams so they are in fact “Ogg FLAC” files (FLAC streams in an Ogg transport layer, which should have OGA extension)?
Anyway as Steve says, once Audacity hands the data to FLAC, however it has handled it, the rest is up to FLAC.
@Gale
They are both LPCM streams which I converted to FLAC then imported into Audacity. I open the 24-bit stream first then I open the 16-bit stream and I copy the missing section that I wish to have in the former stream in order to have my audio sync.
@DVDdoug
I tried your idea, same outcome (which I actually thought would work). The solution seems to be to export to 24-bit WAV and have Eac3to do its conversion (which also uses libFLAC 1.3.1) to FLAC. I’m not sure what is being done differently by these two programs but it doesn’t seem right. MediaInfo identifies the version of libFLAC used by Audacity as 1.0.4 not 1.3.1 despite that the release notes for Audacity 2.1.1 say it’s using 1.3.1.
What app exactly converted to FLAC? Can we get hold of example files that demonstrate the issue?
Can you be more specific in case it is relevant. Do you mean File > Open… or File > Import > Audio… ? Are you doing copy of all the 16-bit file, or only a part of it? And then do you paste into the 24-bit file and Export Selection?
That is a bug, which will be fixed in the next 2.1.2 release of Audacity. 2.1.1 is indeed using libFLAC 1.3.1.
Eac3to converted it from LPCM to FLAC as it is easy for me to script this when I deal with *.m2ts files (containers) on blurays. A sample of the 16/24-bit clip can be found here. The 16-bit stream lasts from 0 to 1840ms inclusive, the rest is 24-bit for this sample.
Import > Audio as I drag and drop the audio files into a blank project after Audacity has launched which is the equivalent. I am only copying sections which are missing in the 24-bit stream. For example, the clip has music (16-bit) playing during an “intermission” half way through. My dubbed track (24-bit) does not have this “intermission” scene at all and therefore is now out of sync for the second half. So I open both in Audacity and go to this “intermission” point in Audacity and I copy the missing section from the 16-bit track to the 24-bit track. After some fine tuning I get it sync’d to the nearest sample. Finally its time to export so I mute the 16-bit track as I do not need it and go to Export Audio since I want all the remaining streams. Playback works great no issues, now I open this up in Eac3to and it identifies it as a 16/24-bit track and not a 24-bit track.
Thanks for the file. To be clear, is this the “dual bit depth” file created by Audacity? I don’t have any tools that would verify the different streams in your attached file, unless presumably I download Eac3to.
If Audacity could see different streams in the file you attached, it would show a dialogue asking which streams to import, as it does for multi-stream OGG files.
I see a tag in your attached file VALID_BITS:16 .
Could we see (if you have the patience) example 16-bit and 24-bit files that Eac3to has converted from LPCM to FLAC? Are you sure those files are “single bit depth”? It may be useful to compare those files with what Audacity produces.
I’ll be honest that I thought multiple FLAC streams in one file required using the Ogg transport layer and that files using this layer should use OGA extension. From https://xiph.org/flac/ogg_mapping.html
The original FLAC format includes a very thin transport system. This system of compressed FLAC audio data mixed with a thin transport has come to be known as ‘native FLAC’. The transport consists of audio frame headers and footers which contain synchronization patterns, timecodes, and checksums (but notably not frame lengths), and a metadata system. It is very lightweight and does not support more elaborate transport mechanisms such as multiple logical streams
Yes this is the “dual bit depth” file. That VALID_BITS being 16 makes me scratch my head as well since the Bit Depth is still listed as 24 bit in MediaInfo and I made sure to double check my export settings as well in Audacity.
Yes, thereby extending the duration of the 24-bit track so that the audio is now in sync.
The “VALID_BITS:16” must be in the original 16-bit FLAC written by eac3to. It’s in the Audacity metadata editor, so exported, because the 16-bit FLAC must have been second in file name order.
I tried by converting mono 16-bit and 24-bit WAV encoded by Audacity 2.1.1 to 16-bit and 24-bit FLAC in eac3to. I guess you have stereo files, but this was convenient to test.
The 24-bit FLAC encoded by eac3to v3.29 (the latest version) says VALID_BITS:24 but the 16-bit FLAC says VALID_BITS: 00.
In Audacity 2.1.1 I pasted some of the eac3to 16-bit FLAC into the eac3to 24-bit FLAC, exported as 24-bit FLAC then looked at the exported FLAC in eac3to. It says the exported file is 24-bits and the log says “The original audio track has a constant bit depth of 24 bits”. It does say your sample file from Audacity is “16/24 bits”.
I don’t think we can take this further without FLAC files encoded by eac3to that would reproduce the problem, in particular the 16-bit FLAC file should say VALID_BITS:16 as apparently yours did.
Also note that eac3to v3.29 is using obsolete libFLAC 1.2.1 (20070917).
I have provided some samples used to create the earlier track (the 16bit and 24bit tracks) at the bottom of this post; these samples were made in Eac3to. To reproduce that track from above, I copied 0 to 1840ms (inclusive) from the 16bit track and pasted it overtop of the 0 to 1840ms section (inclusive) of the 24-bit track. Generally, I would just insert the missing segment; in this sample though I had already added a delay to sync the audio hence why I’m pasting on top of that section. You’re right that Eac3to uses an outdated version out of the box but since it is just a libFLAC dll library that it uses I just grabbed the latest 1.3.1 and rreplaced it. Haven’t looked back since.
I cannot reproduce it in 2.1.2-alpha with your attached input files, either importing them at the default 32-bit Default Sample Format, or at 24-bit Default Sample Format (which means that both files import into Audacity at 24-bit resolution rather than at 32-bit float resolution). Eac3to says the exported file is 24-bit. Eac3to is using the shipped (outdated) libFLAC DLL from 2007, but I don’t think that matters.
I notice your attached input files show “VALID_BITS: 00”, not the “VALID_BITS: 16” of the Audacity-exported file you posted (which implied that at least one of your unposted input files contained a “VALID_BITS: 16” tag).
If I use a tag editor to change the “VALID_BITS: 00” tag in the 16-bit file to “VALID_BITS: 16”, then name the imported files so that the 16-bit file is imported last and so the exported tag reads “VALID_BITS: 16”, then eac3to says the exported file is 16/24 bit.
If I then use a tag editor to change the tag to “VALID_BITS: 00” or to “VALID_BITS: 24”, or if I remove that tag, eac3to says the file is 24-bit.
I conclude this is not an Audacity issue, but an issue that arises in eac3to if the tag in the exported 24-bit file says “VALID_BITS: 16”. If you don’t want eac3to to report 16/24 bit for a 24-bit file, please adjust or remove the tag when you export.