FLAC 24bit to 16bit removing zeros + audio delays

[ndjamena]

Has anything been done about the 16 bit in 24 bit issue?

I've decided to start using MakeMKV to rip to FLAC during the initial rip, but I still need to extract it and check with EAC3To to see if it's 16 or 24 bit. If it's not possible to check the stream before a rip, could MakeMKV at least report at the end of a rip on whether the audio turned out to be 16 or 24 so we know what to do with it?

[dannyboy48888]

MakeMKV is a stream transport tool first, and does that job well. With DTS it does indeed say if it's 24bit when the MA stream is clicked on. As for determining if it's "actual" 16 or 24bit... without processing the whole file you can't determine if it's null data in the uppper 8-bits in the whole stream or not (I've seen some movies have 24-bit data for 5mins then 0's the rest of the title) and is probably better suited for other tools anyway.

[ndjamena]

I'm processing the whole file and converting the DTS-MA/TrueHD to FLAC, so MakeMKV is processing the whole file and every single bit in the audio streams is being processed, decoded and analysed. I'm just wondering if it's possible for MakeMKV to keep tabs on the conversion and report afterwards if it's 16 or 24 bits so I don't have to extract it unnecessarily afterwards to check.

I have been doing it using EAC3To quite happily until now. If I can get MakeMKV do the conversion to FLAC I doubt it will slow the process down much, if MakeMKV says it's 24 bit I can just move onto the next step, if it says it's 16 bit, I can extract the FLAC, reprocess it with EAC3To with no chance of a dtsdecoderdll.dll channel layout problem sneaking into the works (assuming that's still a problem).

Mike is guilting me into using MakeMKVs audio encoding abilities, but as things stand I can't find any actual use for them.

[ndjamena]

Actually, if he added the numbers 16 or 24 to the Track names, I could easily add code to my batches so they know exactly what to do with them without me needing to take any notice what-so-ever.

[mike admin]

Has anything been done about the 16 bit in 24 bit issue?

I've decided to start using MakeMKV to rip to FLAC during the initial rip, but I still need to extract it and check with EAC3To to see if it's 16 or 24 bit. If it's not possible to check the stream before a rip, could MakeMKV at least report at the end of a rip on whether the audio turned out to be 16 or 24 so we know what to do with it?

Still on the to-do list... Sorry for waiting.

[BluFix]

Hi, just wanted to ask if this has been implemented and if so, whether it has been tested successfully. Thanks for your excellent work on MakeMKV!

The full track analysis is a no-go for MakeMKV, as it converts in a single pass. However I do see the value of this feature. I'm thinking of an approach that should work for all practical purposes - scan about 30 random places in a file, about 1 second each, and if all of them are 16-bit then declare the stream as 16-bit. This scan should only take few seconds. The parameters for the scan (number of points, duration, and whether to scan at all) will be set in profile. In the very unlikely event that all file is 16-bit and 1 second is 24-bit, you'll get a warning and somewhat broken audio. Then you'll have to redo the file with different profile.

[yorgo]

Hi, just wanted to ask if this has been implemented and if so, whether it has been tested successfully. Thanks for your excellent work on MakeMKV!

The full track analysis is a no-go for MakeMKV, as it converts in a single pass. However I do see the value of this feature. I'm thinking of an approach that should work for all practical purposes - scan about 30 random places in a file, about 1 second each, and if all of them are 16-bit then declare the stream as 16-bit. This scan should only take few seconds. The parameters for the scan (number of points, duration, and whether to scan at all) will be set in profile. In the very unlikely event that all file is 16-bit and 1 second is 24-bit, you'll get a warning and somewhat broken audio. Then you'll have to redo the file with different profile.

It's been almost 3 years since this thread began and I wonder how valid the need for implementing is. Storage has gotten larger and cheaper, and the thought of manipulating or re-processing an audio stream just seems like an additional step that could potentially lead to problematic playback or file corruption. Perhaps I'm just paranoid and no disrespect intended but if it is still on the to-do list, should it be high priority? My 2 cents only. Y

[BluFix]

It's been almost 3 years since this thread began and I wonder how valid the need for implementing is. Storage has gotten larger and cheaper, and the thought of manipulating or re-processing an audio stream just seems like an additional step that could potentially lead to problematic playback or file corruption

Yes, storage is larger and cheaper but that doesn't mean it's ok to waste unnecessary space. About Mike's suggested solution, I'm not sure what happens if a stream will be declared my MakeMKV as 16bit - will it down-convert automatically or is it something the user will have to do manually?