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: New foo_input_dts plugin (Read 5621 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

New foo_input_dts plugin

foo_input_dst finally was converted to use latest dcadec code from ffmpeg and now is able to decode all variants of dts.
But still not everything works as expected.
1) 0.6.1 reports bitdepth and bitrate for DTS-HD MA (with lossy core) stream only if it is packed in matroska. It doesn't report bitdepth and bitrate if it is in *.dts container. It reports bitrate (but no bitdepth) for this stream in *.mp4.
0.5.5 reports bitdepth and bitrate for this stream in  both *.dts and matroska. Also 0.5.5 reports "Encoding" for *.dts as lossless, but 0.6.1 reports "Encoding" as lossy. Sample - https://www.dropbox.com/s/pt6tm0eimyk4ivp/DTS-HD%20MA.dtshd?dl=1 Note that current standalone Mediainfo is wrong about this file (it is unable to detect lossy core presence).
2) 0.6.1 is unable to report bitdepth, bitrate and even duration for this pure lossless DTS-HD MA (WITHOUT lossy core) stream in *.dts container. It is able to report bitrate and duration (but still no bitdepth) for this stream in matroska and *.mp4.
0.5.5 reports bitdepth, bitrate and duration for this stream in *.dts, but doesn't report bitdepth for this stream in matroska. And again, 0.5.5 reports "Encoding" for *.dts as lossless, but 0.6.1 reports "Encoding" as lossy. Sample - https://www.dropbox.com/s/nnhja057tou1j0m/Pure%20Lossless%20DTS-HD%20short.dts?dl=1.
Both 0.5.5 and 0.6.1 were tested in fb2k 1.4.2 beta 1.
 

Re: New foo_input_dts plugin

Reply #1 –
Quote from: Rollin on
f1) 0.6.1 reports bitdepth and bitrate for DTS-HD MA (with lossy core) stream only if it is packed in matroska. It doesn't report bitdepth and bitrate if it is in *.dts container. It reports bitrate (but no bitdepth) for this stream in *.mp4.
FFmpeg doesn't report the "actual" bitrate, if any. It always decodes to 32 bit floating point.

Quote from: Rollin on
0.5.5 reports bitdepth and bitrate for this stream in  both *.dts and matroska. Also 0.5.5 reports "Encoding" for *.dts as lossless, but 0.6.1 reports "Encoding" as lossy. Sample - https://www.dropbox.com/s/pt6tm0eimyk4ivp/DTS-HD%20MA.dtshd?dl=1 Note that current standalone Mediainfo is wrong about this file (it is unable to detect lossy core presence).
I can fix this, but only if I assume certain "profiles" are lossy or lossless.

Which of these is lossy? Which is lossless? Which is "supposed" to have a fixed bit depth, even though FFmpeg is decoding them all to floating point anyway?

Quote from: Rollin on
2) 0.6.1 is unable to report bitdepth, bitrate and even duration for this pure lossless DTS-HD MA (WITHOUT lossy core) stream in *.dts container. It is able to report bitrate and duration (but still no bitdepth) for this stream in matroska and *.mp4.
0.5.5 reports bitdepth, bitrate and duration for this stream in *.dts, but doesn't report bitdepth for this stream in matroska. And again, 0.5.5 reports "Encoding" for *.dts as lossless, but 0.6.1 reports "Encoding" as lossy. https://www.dropbox.com/s/nnhja057tou1j0m/Pure%20Lossless%20DTS-HD%20short.dts?dl=1.
Both 0.5.5 and 0.6.1 were tested in fb2k 1.4.2 beta 1.
I can fix the reporting lossy/lossless easily, as I can hard code which profiles are reported as lossy or lossless. But I can't easily handle bit depth, as FFmpeg doesn't appear to report that. I can check anyway, though.

E: I've fixed most or all of your issues, but I'd still recommend muxing raw DTS into either MP4 or Matroska for faster seeking and length detection.

Re: New foo_input_dts plugin

Reply #2 –
Does version 0.6.3 not play nice with XP? This is the error message fb2k 1.4.2 beta 1 displays after it's installed.
Thanks.

Failed to load DLL: foo_input_dts.dll
Reason: This component is missing a required dependency, or was made for different version of foobar2000.

PS. Version 0.5.5 works fine but I don't know where to find the newer version(s) such as 0.6.1 mentioned in the opening post.

Re: New foo_input_dts plugin

Reply #3 –
Plugin is based on ffmpeg now. And modern versions of ffmpeg don't support XP.

Re: New foo_input_dts plugin

Reply #4 –
I've no idea what makes ffmpeg XP friendly, or not, but it's apparently do-able. I've been downloading XP friendly versions from here.
I just realised there's a more recent release than the one I've been using. It's dated 2018-12-22. I've been using the version dated 2018-08-26 since it was released without any problems.

Doesn't fb2k use ffmpeg for decoding?

Not that it's a big deal. I can still use version 0.5.5 of the DTS decoder, or ffmpeg for decoding DTS via the ffmpeg decoder wrapper.

Cheers.

Re: New foo_input_dts plugin

Reply #6 –
libavutil wants bcrypt (Vista+) because of this patch.

BTW, it seems that swresample DLL is not necessary for this plugin.

Re: New foo_input_dts plugin

Reply #7 –
swresample disabled. BCrypt commit reverted. Hopefully, it works on XP now.

Re: New foo_input_dts plugin

Reply #8 –
Yep, it's all joy and happiness for XP again (version 0.6.5 of foo_input_dts).
Thanks!

I don't really understand the point of the original BCrypt patch. Not that I know anything about software, but to me it seemed to take not supporting XP a step further and deliberately prevented it from working.  Maybe there's a reason for it I don't understand? I suspect the same patch also broke the CLI version of the x264 encoder MeGUI uses.

Anyway.... thanks again!

Re: New foo_input_dts plugin

Reply #9 –
Quote from: yetanotherid on
Not that I know anything about software, but to me it seemed to take not supporting XP a step further and deliberately prevented it from working.
Deliberately? Developers don't care that FFmpeg cannot work on Windows 3.1, because this OS is not supported. Similarly, developers don't care that some patch made FFmpeg incompatible with WinXP, because WinXP is not supported.

Quote from: yetanotherid on
Maybe there's a reason for it I don't understand?
For example: bcrypt is supported in UWP apps.

Re: New foo_input_dts plugin

Reply #10 –
Quote from: lvqcl on
Deliberately? Developers don't care that FFmpeg cannot work on Windows 3.1, because this OS is not supported. Similarly, developers don't care that some patch made FFmpeg incompatible with WinXP, because WinXP is not supported.

Fortunately kode54 isn't one of those developers. He cared enough to make foo_input_dsp work on XP again.
I assume Peter is a developer and fb2k wouldn't be the only software using ffmpeg that still supports XP, so maybe putting all developers in the same category wouldn't be terribly accurate. Comparing XP to Win3.1 seems like a huge stretch.
To me it appeared (and I don't really understand how it all works) that adding bcrypt mightn't have required removing wincrypt support, but maybe that's wrong and it's one or the other.

Anyway, I was really only questioning whether the patch was/is something that couldn't be avoided or postponed, or if XP functionality could've been left intact a while longer, even if it's not a supported OS as such. Not that it bothers me too much. Sooner or later I'll bite the bullet and dump Windows for Linux. That's the plan, at least....

Re: New foo_input_dts plugin

Reply #11 –
I only continue to support XP because it's the lowest platform that foobar2000 still supports. I only bend over backwards this way because most of the time, it's painless to do so. I would consider dropping XP if the player did, but I would probably archive the last release of any given component to still support XP for at least a while, like I did with 0.8.x components back when 0.9 dropped Windows 9x/ME.

It may have been possible to dynamically load it, but probably not if you're building for UWP.

Linux support need not preclude older machine owners so much, as the kernel tends to carry a lot of drivers around for years to come. But legacy apps tend to break after a few years if they aren't updated to modern versions of libraries.

I support my Cog audio player on macOS, but I won't be building that so much soon, since I'm letting my Apple Developer subscription expire for a while.

I also support some stuff on Linux, such as DeaDBeeF and Audacious plugins.

There are always alternatives for older machines, and they don't necessarily involve using legacy operating systems. Of course, good luck trying to use modern desktop environments without at least 2GB of RAM available.

Re: New foo_input_dts plugin

Reply #12 –
kode54,
I'm experiencing some foo_input_dts and ffmpeg related oddness. I was having issues converting a couple of flac files yesterday. It produced an error message about invalid data in the flac stream. I tried reverting to an earlier version of fb2k and your AC3/DTS plugins (from what I read in another thread I thought they could be causing it) but after going back to fb2k 1.42 beta 2 and the latest version of your plugins the problem seems to have gone away. However....

I seem to be in a perpetual upgrade loop with foo_input_dts. Checking for updated components indicates the latest version is 0.6.7, but after updating foo_input_dts, fb2k shows the installed version as 0.6.6 and checking for updates repeats the process.

I discovered the next problem while converting a couple of DST movie soundtrack files to AAC. The conversions ended with the following warning.

2 out of 2 tracks converted with major problems.
Source: "E:\Movie 1.dts"
  Decoder produced garbage at 2:55:55.584
Source: "E:\Movie 2.dts"
  Decoder produced garbage at 2:19:53.333

The output files are probably okay though. The issue seems to be an incorrect duration is reported for DTS. When loaded into a playlist the files above display as 2:52:50.037 and 2:17:25.794 respectively. For both, fb2k does continue playing the audio past the reported duration.

After reverting back to foo_input_dts 0.5.5, fb2k reports what I assume are the correct durations... 2:55:55.584 and 2:19:53.333.

My best guess is it relates to ffmpeg reporting 1536 kbps for the bitrate when it's really 1509 kbps. In the first screenshot below you can see %bitrate% displays the bitrate as 1536 while the audio isn't playing. The second screenshot shows it changes to 1509 when it is (courtesy of the text display plugin).

For the record, the same incorrect durations are displayed when decoding with the ffmpeg decoder wrapper, but when re-encoding there's no error message. No matter which decoding method is used, fb2k reports exactly the same number of samples for the encoded AAC, and for my two examples above, the durations fcr the encoded AAC versions were 2:55:55.584 and 2:19:53.333.

So I think everything is actually okay, aside from the error message, although it'd be nice to have the duration reported correctly. Any idea why some programs display DTS as 1536 kbps while other show it as being 1509?

Cheers.

PS. Thanks for the continued XP support!

Re: New foo_input_dts plugin

Reply #13 –
Quote from: yetanotherid on
The issue seems to be an incorrect duration is reported for DTS. When loaded into a playlist the files above display as 2:52:50.037 and 2:17:25.794 respectively. For both, fb2k does continue playing the audio past the reported duration.

After reverting back to foo_input_dts 0.5.5, fb2k reports what I assume are the correct durations... 2:55:55.584 and 2:19:53.333
How your DTS files were created? For files created with DTS-HD Master Audio Suite duration is displayed almost perfectly with foo_input_dts 0.6.6. Difference is only in milliseconds from original source wav regardless of incorrectly reported bitrate and it is caused by ffmpeg ignoring info about padding in dts files.
Can you try to repack your files from dts to dts with ffmpeg and see if reported duration will change?
Nevermind. I took dts track out from mkv movie and duration displayed by 0.6.6 was wrong by by almost 3 minutes.

As kode54 already said
Quote from: kode54 on
I'd still recommend muxing raw DTS into either MP4 or Matroska for faster seeking and length detection.

Re: New foo_input_dts plugin

Reply #14 –
Rollin,
I guess I was playing around and writing this post while you edited yours, but here it is anyway.

The DTS was ripped from Bluray. I've tried three different DTS files (already ripped) and I tried repacking one of the DTS files with ffmpeg but nothing changed. It was almost the same when I re-encoded the DTS file at 1509.75 kbps myself (ffmpeg), although the bitrate was shown as 1512 kbps while it played and the displayed duration was a little different. So far, the only time the bitrate and duration display correctly is when I remux the DTS as an MKA with MKVToolNixGUI.

When I switch back to foo_input_dts 0.5.5, the original DTS, the repacked version, the version re-encoded with ffmpeg at 1509.75 kbps and the version remuxed as an MKA, all display with exactly the same duration and exactly the same total number of samples. The main downside is it's really slow to open DTS files, and equally slow to begin playing them.

Re: New foo_input_dts plugin

Reply #15 –
FFmpeg is not detecting the length, and I am using a faulty method to detect the length in that case. If in doubt, don't bother with raw .DTS files, and always use either MKA or MP4 container.

Upgrade loop dealt with.