Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: DTS decoding in foobar v2 (Read 6837 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

DTS decoding in foobar v2

There don't seem to be any DTS related topics since 2019, so starting a new one.

v2 comes with 'built in' DTS decoding , replacing  the 3rd party foo_input_dts plugin

I observe that a DTS 96/24 input decodes to a 96/16 .wav file.

Does v2  use ffmpeg to decode DTS?

Re: DTS decoding in foobar v2

Reply #1 –
I don't know anything about DTS, but under Preferences > Playback > Decoding:
"FFmpeg DTS Decoder" (FFmpeg 6.0)

Re: DTS decoding in foobar v2

Reply #2 –
Yes, it uses ffmepeg but... Your DTS is lossy, not lossless. fb2k has always output 16 bit wav for lossy sources by default when using converter. Lossy codecs have no fixed bitdepth. DTS profiles "DTS 96/24" and "DTS-HD High Resolution Audio" are lossy. So, talking about 24 bit regarding to them is just marketing bullshit. The only profile of DTS which is lossless is "DTS-HD Master Audio". Lossless DTS in fb2k v2 is decoded and converted as it should to its real bitdepth.
Here is sample of lossless DTS for you to assure - https://www.dropbox.com/s/cc2jfpqdm5agxyw/DTS-HDMA-3.1%20L%20R%20C%20BC.dtshd?dl=1

Re: DTS decoding in foobar v2

Reply #3 –
Quote from: Bogozo on
Yes, it uses ffmepeg but... Your DTS is lossy, not lossless. fb2k has always output 16 bit wav for lossy sources by default when using converter. Lossy codecs have no fixed bitdepth. DTS profiles "DTS 96/24" and "DTS-HD High Resolution Audio" are lossy. So, talking about 24 bit regarding to them is just marketing bullshit. The only profile of DTS which is lossless is "DTS-HD Master Audio". Lossless DTS in fb2k v2 is decoded and converted as it should to its real bitdepth.
Here is sample of lossless DTS for you to assure - https://www.dropbox.com/s/cc2jfpqdm5agxyw/DTS-HDMA-3.1%20L%20R%20C%20BC.dtshd?dl=1

My understanding is that '96/24' in DTS 96/24 refers to the properties of the audio that was input to the encoder. 

Regardless of the fact that lossy codecs have no fixed bit depth, the decoded-to-PCM output has to have *some* bit depth value.

How is 16 bits a more 'real' bit depth , in that case, than 24?

Here, btw , it is asserted that ffmpeg decodes to 32 bit floating point.  If so there must be a further conversion to produce the final output .wav
https://hydrogenaud.io/index.php/topic,117142.msg966931.html#msg966931




Re: DTS decoding in foobar v2

Reply #4 –
Quote from: krabapple on
My understanding is that '96/24' in DTS 96/24 refers to the properties of the audio that was input to the encoder.
Right. But you also can encode to mp3 from 24 bit source. But no one calls it "24 bit mp3" or "high resolution mp3". Of course mp3 does not support 96 kHz, but Vorbis and AAC do. And still no one calls it "24 bit Vorbis" or "24 bit  AAC".

Quote from: krabapple on
How is 16 bits a more 'real' bit depth , in that case, than 24?
This is just how fb2k' s converter by default handles converting from lossy sources. It always was this way. Why such behavior was chosen this is another question. And this behavior has nothing to do with DTS or ffmpeg. If you want to convert lossy to other bitdepth than 16, just set bitdepth manually in converter settings.

Re: DTS decoding in foobar v2

Reply #5 –
Quote from: Bogozo on
Quote from: krabapple on
My understanding is that '96/24' in DTS 96/24 refers to the properties of the audio that was input to the encoder.
Right. But you also can encode to mp3 from 24 bit source. But no one calls it "24 bit mp3" or "high resolution mp3". Of course mp3 does not support 96 kHz, but Vorbis and AAC do. And still no one calls it "24 bit Vorbis" or "24 bit  AAC".

Well, DTS is a commercial product with a proprietary encoder and mp3 isn't. So inevitably, marketing is involved.  But that's beside the point.  I'm talking about what format the *decoded* (wav) file should be.  Why 'should' an mp3 that originated from 24 bit audio be decoded to 16 bit? Why not 24?

Quote
Quote from: krabapple on
How is 16 bits a more 'real' bit depth , in that case, than 24?
This is just how fb2k' s converter by default handles converting from lossy sources. It always was this way. Why such behavior was chosen this is another question. And this behavior has nothing to do with DTS or ffmpeg. If you want to convert lossy to other bitdepth than 16, just set bitdepth manually in converter settings.

I'm not asking how to get 24 bit outputs, I'm aware of options*.  I'm asking why 24 bit inputs to an encoder would be decoded to 16 bit outputs.   "It's always been this way" isn't really much of a reason.  And of course it is about ffmpeg, because foobar v2 uses ffmpeg (which was my initial question, answered by Gus, thanks Gus). 

this  line of questioning for me started with observing that some 96/24 DTS decodes (to 96/24 wav ) have clipping, and wondering whether this was because the input audio was already clipped , or was clipped by lossy encoding.


*I know of two softwares that by default decode '96/24' DTS input to 96kHz/24 bit wav output:  Audiomuxer and DVD Audio Extractor.   Whether a 24 bit output is audibly necessary is a fair question, but it is at least 'consistent'.    In both cases the sample rate and bit depth of the output are also user-configurable.

Re: DTS decoding in foobar v2

Reply #6 –
According to https://en.wikipedia.org/wiki/DTS_(company)#DTS_96/24 , DTS 96/24 means it has a correction file that - together with the lossy "core" DTS file - makes for lossless 96/24. And it might reside in the video zone rather than the audio zone.

As far as I understand https://hydrogenaud.io/index.php/topic,88921.msg821523.html#msg821523 @krabapple did find a way to rip the 96/24 out.

Re: DTS decoding in foobar v2

Reply #7 –
Quote from: Porcus on
According to https://en.wikipedia.org/wiki/DTS_(company)#DTS_96/24 , DTS 96/24 means it has a correction file that - together with the lossy "core" DTS file - makes for lossless 96/24.

This?
Quote
DTS 96/24, introduced in May 2001 allows the delivery of 5.1 channels of 24-bit, 96 kHz audio and high quality video on the DVD-Video format. Prior to the development of DTS 96/24, it was only possible to deliver two channels of 24-bit, 96 kHz audio on DVD Video. DTS 96/24 can also be placed in the video zone on DVD-Audio discs, making these discs playable on all DTS-compatible DVD players. DTS 96/24 is implemented as a core DTS stream plus an extension containing the deltas to enable 96/24 sound reproduction.
Even there is no mention of lossless. DTS 96/24 is not lossless.
Also, i have pirated copy of DTS-HD Master Audio Suite, so i can easily test it. Here is 24/96 wav and DTS 96/24 created from that wav - https://www.dropbox.com/s/vcn887q9j8ih7i5/wdwsdedfef.zip?dl=1

Quote from: Porcus on
As far as I understand https://hydrogenaud.io/index.php/topic,88921.msg821523.html#msg821523 krabapple did find a way to rip the 96/24 out.
Things have changed since 2013. Nowadays ffmpeg decodes all DTS profiles  just fine.

Re: DTS decoding in foobar v2

Reply #8 –
Quote from: Bogozo on
Even there is no mention of lossless. DTS 96/24 is not lossless.
All right, there is "an extension containing the deltas to enable 96/24 sound reproduction" which is likely copied and pasted from some exposition that wants you to believe that "the deltas" means "the difference between the PCM and the DTS core stream" - when indeed it is "the difference between whatever and the DTS core stream"?

Fooled me, obviously.
And spawns the next question: since other DTS formats are "core DTS + correction files", which ones are still lossy?

Re: DTS decoding in foobar v2

Reply #9 –
Quote from: Porcus on
Quote from: Bogozo on
Even there is no mention of lossless. DTS 96/24 is not lossless.
All right, there is "an extension containing the deltas to enable 96/24 sound reproduction" which is likely copied and pasted from some exposition that wants you to believe that "the deltas" means "the difference between the PCM and the DTS core stream" - when indeed it is "the difference between whatever and the DTS core stream"?

Fooled me, obviously.
And spawns the next question: since other DTS formats are "core DTS + correction files", which ones are still lossy?

+1
Current discussion made me think about it too - which particular versions of DTS and Dolby are really lossless?
Are those only DTSHDMA and DTrueHD plus those "new object ones" (Atmos and :X)?
I always thought that DTS96/24 is lossless (lossy core plus smth), the same with DTS HD HRA. Are you sure that those two are really lossy?

Re: DTS decoding in foobar v2

Reply #11 –
Quote from: Porcus on
According to https://en.wikipedia.org/wiki/DTS_(company)#DTS_96/24 , DTS 96/24 means it has a correction file that - together with the lossy "core" DTS file - makes for lossless 96/24. And it might reside in the video zone rather than the audio zone.

That might be relevant for ripping, but ripping's not an issue.

Quote
As far as I understand https://hydrogenaud.io/index.php/topic,88921.msg821523.html#msg821523 @krabapple did find a way to rip the 96/24 out.

Years ago!  I'm not having a problem ripping or decoding 96/24 DTS files.  I'm questioning how and when DTS encoding and decoding practices affect peak level, basically.   My inquiry was complicated by the fact that some DTS decoders behave differently than others with DTS 96/24 encodes.

Re: DTS decoding in foobar v2

Reply #12 –
Quote from: Porcus on
Quote from: Bogozo on
Even there is no mention of lossless. DTS 96/24 is not lossless.
All right, there is "an extension containing the deltas to enable 96/24 sound reproduction" which is likely copied and pasted from some exposition that wants you to believe that "the deltas" means "the difference between the PCM and the DTS core stream" - when indeed it is "the difference between whatever and the DTS core stream"?

Fooled me, obviously.
And spawns the next question: since other DTS formats are "core DTS + correction files", which ones are still lossy?


DTS 96/24 only claims to include content above 20kHz that is excluded in the 'core' encode...it is still a lossy psychoacoustic codec though.  It doesn't claim to be lossless.   The only lossless DTS codec is DTS HD Master Audio

Re: DTS decoding in foobar v2

Reply #13 –
Quote from: Bogozo on
Things have changed since 2013. Nowadays ffmpeg decodes all DTS profiles  just fine.

Depends on the meaning of  'just fine'.   It still decodes DTS 96/24 to 16 bit audio, AFAICT. 

Re: DTS decoding in foobar v2

Reply #14 –
Quote from: wojak on
+1
Current discussion made me think about it too - which particular versions of DTS and Dolby are really lossless?
Are those only DTSHDMA and DTrueHD plus those "new object ones" (Atmos and :X)?

Don't know about the new object-oriented ones, but the other two are the only lossless 'old school' versions of DTS and DD.

Quote
I always thought that DTS96/24 is lossless (lossy core plus smth), the same with DTS HD HRA. Are you sure that those two are really lossy?

Pretty confident that, like all lossy codecs I know of, >20kHz content isn't the only data that the DTS psy model discards. But I guess a delta of lossless input vs  decoded DTS 96/24 of same would tell the tale.

Re: DTS decoding in foobar v2

Reply #15 –
Quote from: krabapple on
Quote from: Bogozo on
Things have changed since 2013. Nowadays ffmpeg decodes all DTS profiles  just fine.

Depends on the meaning of  'just fine'.   It still decodes DTS 96/24 to 16 bit audio, AFAICT. 

FFmpeg decodes it just fine. Use different PCM encoder, you can save even to double precision floating-point format.
Knowledge is power if you have it.
Ignorance is bliss for you.
Please remove my account from this forum.

Re: DTS decoding in foobar v2

Reply #16 –
Quote from: krabapple on
It still decodes DTS 96/24 to 16 bit audio
ffmpeg doesn't "decode DTS 96/24 to 16 bit audio". ffmpeg command line tool by default truncates output to 16 bit if output format is wav. It does so regardless of what input format is, DTS or anything. But you can set output bitdepth manually or use other output format. For example, it does't truncate to 16 bit if output format is FLAC.

Re: DTS decoding in foobar v2

Reply #17 –
Quote from: mycroft on
Knowledge is power if you have it.
Yeah, a power that ffmpeg refuses to wield even when the devs have the power to know. We need an fflossless utility that not only knows what to do, but is willing to employ the power of knowledge to make ffmpeg useful for any other lossless operation than -c copy.
Willing to take on the challenge ... ?

For users' empowerment, here is a partial list of where to avoid ffmpeg unless as a last resort you are willing to go through file by file with ffmpeg -i to meticulously read output that ffmpeg knows but refuses to utilize and manually feed it into the command line:

* ffmpeg obtains the knowledge that input is 32-bit float. ffmpeg converts to integer without even warning the user that now it has introduced major clipping. ffmpeg devs have the knowledge that this behaviour is destructive and unnecessary.
* Yes even when it knows how to warn users ... for seemingly related reason:
ffmpeg -i floatfile.wav outfile.flac returns "encoding as 24 bits-per-sample, more is considered experimental. Add -strict experimental if you want to encode more than 24 bits-per-sample". Aha, so I take ffmpeg's kind advice:
ffmpeg -i floatfile.wav -strict experimental -y outfile.flac returns no warning, and encodes lossy - and might clip from here to Hades.
* A more powerful ffmpeg would be able to use the knowledge that lossless conversion from 24-bit FLAC/ALAC to 24-bit WavPack is possible - and do it, rather than going 32-bit.
* A more powerful ffmpeg would know that 8-bit FLAC is a thing.
* A more powerful ffmpeg would be able to use the knowledge of the number of channels, and refuse to write non-compliant WavPack files that nothing can read (it seems ffmpeg itself cannot, although I haven't tried after last upgrade).


(Uh, and since ffmpeg takes pride in cracking and reverse-engineering every lossless format more obscure than OptimFROG:
MPEG4-ALS float and -z, then? Because the the reference implementation is so crash prone it might render .als files unreadable. Basically you got an ISO-standardized format where the only known implementation might sometimes crash on its own encodes, rendering them completely undecodable. ffmpeg support would enable users to save some content that nothing else could save.
Hypothetical users, that is - the real number of users is likely not much more than RKAU lossless.)

Re: DTS decoding in foobar v2

Reply #18 –
8-bit FLAC is supported, do not take drugs.
Please remove my account from this forum.

Re: DTS decoding in foobar v2

Reply #19 –
Well here I discovered something even worse than the FLAC handling:
ffmpeg -i 8bit.wav 8bit.wav-ffmpeg-to.wv produces nonsense. Which makes wvunpack err out and which makes fb2k plays back as static. To the extent that is "even worse" than clipping ... at least it can be heard immediately.

You can file a bug report yourself I guess?


Quote from: mycroft on
8-bit FLAC is supported, do not take drugs.
O'Rlyeh? It does handle "8-bit FLAC" streams, but it does not know that "8-bit" FLAC is a thing:
ffmpegging 8bit.<anything> to FLAC returns a 16-bit FLAC, not an 8-bit FLAC.
ffmpegging 8bit.flac to <anything lossless> returns a 16-bit, not an 8-bit.

Then ffmpegging 8bit.wav to <anything> yields:
16 bit FLAC, as pointed out already. And 16 bit ALAC.
Makes erroneous WavPack file (but 8 bit ...)
8 bit TTA that reference tta.exe refuses to handle - but ffmpeg does TTA much better than reference tta.exe anyway, in case anyone is careless enough to want to use that format.

Version:
Code: [Select]
ffmpeg version 6.0-essentials_build-www.gyan.dev Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 12.2.0 (Rev10, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-sdl2 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libgme --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libtheora --enable-libvo-amrwbenc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-librubberband
  libavutil      58.  2.100 / 58.  2.100
  libavcodec     60.  3.100 / 60.  3.100
  libavformat    60.  3.100 / 60.  3.100
  libavdevice    60.  1.100 / 60.  1.100
  libavfilter     9.  3.100 /  9.  3.100
  libswscale      7.  1.100 /  7.  1.100
  libswresample   4. 10.100 /  4. 10.100
  libpostproc    57.  1.100 / 57.  1.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

Re: DTS decoding in foobar v2

Reply #20 –
Quote from: Bogozo on
Quote from: krabapple on
It still decodes DTS 96/24 to 16 bit audio
ffmpeg doesn't "decode DTS 96/24 to 16 bit audio".

Ah, semantics.  Ok, I input a DTS encoded file to ffmpeg.  A .wav PCM file comes out.  Something  decoded that DTS data, yes?
So is your beef with "to 16 bit audio"? 

Quote
ffmpeg command line tool by default truncates output to 16 bit if output format is wav. It does so regardless of what input format is, DTS or anything.

That's good to know, thanks. Question is....why do that?   Seems suboptimal....the truncation part, that's not best practice when going from higher bit to 16, is it?
Quote
But you can set output bitdepth manually or use other output format. For example, it does't truncate to 16 bit if output format is FLAC.

Also good to know, thanks. 

But again I only asked because f2K uses ffmpeg.   I'll try setting output to FLAC and see what happens. I see if doing that actually changes an ffmpeg command parameter, or just pipes the ffmpeg 16 bit output wav to a flac encoder.

It all makes me curious how the other tools arrange to decode a '96/24' DTS file to 96/24 wav (or flac)...by default. 


Re: DTS decoding in foobar v2

Reply #21 –
Quote from: krabapple on
Seems suboptimal....the truncation part, that's not best practice when going from higher bit to 16, is it?
Of course it is suboptimal and truncation isn't best practice. I'm not advocating this behavior, just telling how it is.

Quote from: krabapple on
But again I only asked because f2K uses ffmpeg.   I'll try setting output to FLAC and see what happens. I see if doing that actually changes an ffmpeg command parameter, or just pipes the ffmpeg 16 bit output wav to a flac encoder.
As it been wrote already: behavior of fb2k's converter is not anyhow connected with default behavior of ffmpeg. Unless you are using ffmpeg.exe through "FFmpeg decoder wrapper" component to decode your files. At least in 32-bit version of fb2k, all internal decoders (including ffmpeg based ones) decode everything to 32bit floating point (maybe in 64-bit version it is 64 bit floating point, i don't know).

Re: DTS decoding in foobar v2

Reply #22 –
Truncation isn't best practice.
Clipping isn't best practice.
And no warning no nothing when clipping and truncating, that isn't best practice.

Re: DTS decoding in foobar v2

Reply #23 –
Quote from: Porcus on
Well here I discovered something even worse than the FLAC handling:
ffmpeg -i 8bit.wav 8bit.wav-ffmpeg-to.wv produces nonsense. Which makes wvunpack err out and which makes fb2k plays back as static. To the extent that is "even worse" than clipping ... at least it can be heard immediately.

You can file a bug report yourself I guess?


Quote from: mycroft on
8-bit FLAC is supported, do not take drugs.
O'Rlyeh? It does handle "8-bit FLAC" streams, but it does not know that "8-bit" FLAC is a thing:
ffmpegging 8bit.<anything> to FLAC returns a 16-bit FLAC, not an 8-bit FLAC.
ffmpegging 8bit.flac to <anything lossless> returns a 16-bit, not an 8-bit.

Then ffmpegging 8bit.wav to <anything> yields:
16 bit FLAC, as pointed out already. And 16 bit ALAC.
Makes erroneous WavPack file (but 8 bit ...)
8 bit TTA that reference tta.exe refuses to handle - but ffmpeg does TTA much better than reference tta.exe anyway, in case anyone is careless enough to want to use that format.

Version:
Code: [Select]
ffmpeg version 6.0-essentials_build-www.gyan.dev Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 12.2.0 (Rev10, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-sdl2 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libgme --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libtheora --enable-libvo-amrwbenc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-librubberband
  libavutil      58.  2.100 / 58.  2.100
  libavcodec     60.  3.100 / 60.  3.100
  libavformat    60.  3.100 / 60.  3.100
  libavdevice    60.  1.100 / 60.  1.100
  libavfilter     9.  3.100 /  9.  3.100
  libswscale      7.  1.100 /  7.  1.100
  libswresample   4. 10.100 /  4. 10.100
  libpostproc    57.  1.100 / 57.  1.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

Very rude person aren't you. The files as encoded from 8bit .wav files here to .wv works bitexact.
Perhaps your 8bit file is so special snowflake that it needs special handling.
You should never ever use ffmpeg again, as you hate it the most.
Please remove my account from this forum.
 

Re: DTS decoding in foobar v2

Reply #24 –
ffmpeg does the same to 8-bit PCM files produced by ffmpeg, so ffmpeg would be much more buggy if you were speaking the truth. Good for ffmpeg that you don't.
https://filebin.net/5itric7h9e3qspeh contains
8bit.wav
8bit.wv created by reference WavPack - works, of course.
8bit.wav-ffmpeg-to.flac created from the .wav by ffmpeg - 16-bit file and not 8-bit file, but apart from that it contains what it should.
8bit.wav-ffmpeg-to.wv is the offending file.

But it isn't about the .wav. Converting it to .aif, to .caf (both endianness) or even to .au (using ffmpeg - attached!) and then ffmpegging over to .wv - what happens? Five identical (and corrupted) .wv files.
wvunpack.exe -v .\8bit.wav-ffmpeg-to.wv returns:
Code: [Select]
 WVUNPACK  Hybrid Lossless Audio Decompressor  Win64 Version 5.6.0
 Copyright (c) 1998 - 2022 David Bryant.  All Rights Reserved.

missing data or crc errors detected in 27 block(s)!  

Edit: and it isn't about the signal. Try ffmpegging the 8-bit.wv to .wv