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.
Recent Posts
91
General - (fb2k) / Re: Title formatting/syntax for proper bitdepth
Last post by Case -
Quote from: wojak on
By the way - if 17th bit comes from halving how should I understand such cases when I see PE=yes but the file reports itself as 17bit (not 24) with TPS?
Sounds like the track uses Peak Extension codes in the wrong places, or the track is too quiet generally for PE to do anything. You can run the track through HDCD scanner and it will report how many frames were altered by PE. I suspect there weren't actually any extended peaks.

I'd like to change decoded_bitspersample to report the actual real decoded bitdepth, like return 16 bits or 17 bits for fake titles depending on settings. But there is a problem, LLE effect will instantly trigger 24-bit accuracy and it's unknown from the first seconds if the code was missing if it will be used later. People may not like decoded_bitspersample changing mid-track.

I hope I don't confuse you furher, but the bit depth reported by TPS is based solely on the lowest bit used by the signal. It could for example report 32 bits for a very quiet signal that could be represented with just two bits if it was amplified. Would there be interest to see the used bit count that computes the unused upper bits?

Quote from: wojak on
PS. I have the same logic (or "unlogicness") when it comes to the "decoded_*" formulas. Those work really well with sacd_input - ex. they provide info that DSD has been decoded to DSD or has been decoded to PCM as both "decoded_samplerate" and "decoded_bitspersample" are not constant and show either 2,8/1 or PCMrate/64 depending on the output option used. We also have "decoded_channels" and "decoded_channel_mask" which always show proper values for DSD. When playing HDCD only "decoded_bitspersample" shows 24 bits and the rest of the fields stay empty which..looks strange/not informative/not pretty. I know that the empty field means that ex. "decoded_samplerate"="samplerate" but what is wrong in explicitly showing it?
The fields are non-standard, they are against foobar2000 logic, a decoder should not report permanent tech info fields (visible in properties dialog) that change depending on user preferences. Tech info fields are supposed to report file specs. I know I kind of abuse this with foo_outinfo, but I don't want to push nonsense any further. Peter has already dropped features from titleformat code because developers abused the system, I don't want such things to happen ever again and most certainly not because I do something stupid.
92
General - (fb2k) / Re: Title formatting/syntax for proper bitdepth
Last post by Case -
Quote from: Defender on
I have a HDCD, when I scan it all tracks have Transcient Filter, none have PE or Gain. If I'm not mistaken none of software solutions are capable of doing anything with Transcient Filter.

When HDCD 1.20+ is configured with Exclude and both subboxes checked, and I play one of those tracks none of the hdcd tags are published, so no way of knowing the track has Transcient Filter.
I know none of the features are enabled when playing, but I do want to know whether a track has Transcient Filter even if the software component can do nothing with it. Maybe a next software component can actually do something with this filter.
That is not happening. The creators dropped the transient filter idea during development as the technology was already patented by someone else. There is not even a hint of mention about transient filters for example in the documentation about HDCD authoring hardware. Also if the idea was to pick a different decoding filters during playback stage, that would not work as there are no bits to tell what filter to use.
93
CUETools / Re: How To Rip & Decode HDCDs In CUERipper?
Last post by Wickedfox -
So I should just keep all hdcd settings off including dectect hdcd encoding in cueTOOLS so it doesn't effect rips of normal cds in cueRipper, and ONLY have them on when it's a hdcd that's playing. Is that correct?
96
General - (fb2k) / Re: Title formatting/syntax for proper bitdepth
Last post by Defender -
I don't see the issue.

The HDCD plugin will detect HDCD signals and takes action upon that. When it detects a track that is fake (according to the settings of the HDCD plugin) or not does not really matter.
Imo decoded_samplerate and decode_bitspersample should always be published for a playing HDCD (fake or not) track.

There is nothing wrong with that, the plugin actually gets the track and processes and decodes it. When it is fake it is decoded (or passed through but that's semantics)  to 44kHz/16bit. Still decoded. So publish those values in decoded_* tags.

I also would not mind at all that in case of such a fake HDCD the %hdcd% would still be set regardless of the settings of the plugin. Key factor for me to detect if it is fake are the published decoded_samplerate/decoded_bitdepth fields.
But they need to be present in order to do so (preferably with %hdcd% available too).

EDIT: I now use the plugin with Exclusive disabled, because for me it is more important to know that in essence it is a HDCD track, then when having Exclusive on just seeing normal flac. So please just publish the missing tags, then I can have best of both worlds.
97
3rd Party Plugins - (fb2k) / Re: foo_vis_vumeter
Last post by oops -
Quote from: p.h. on
Please find crash log attached. This time, foobar2000 doesn't crash at the very moment I click OK to add the VU Meter. It looks as if it manages to load background for the visualisation, so it takes a few seconds.
It is loading everything now including the BIN files and DirectX gets fully set up. Window is created and the component begins rendering and painting the first frame. But it is now failing on the EndDraw() call during/after drawing the rounded rectangle background. This is a fundamental and simple Direct2D operation. I don't know where to go from here. I am personally very saddened that Haswell Processor Graphics don't seem to be working with the DirectX 12 API.
100
General - (fb2k) / Re: Title formatting/syntax for proper bitdepth
Last post by wojak -
Quote from: Case on
I don't understand what love you hold towards these fake HDCDs. If a track is not HDCD it should get absolutely no special HDCD processing done to it. You need to make up your mind what you consider a fake HDCD.
In order to know if the track is a fake HDCD one must have an option to see it - if we exclude a track from being treated as HDCD (real or fake) foobar sees it (and we see it) as normal CD. Even if the track is the fakest of possible HDCDs (but somehow reports itself as HDCD) and the decoder decodes it to 24 bits...we loose nothing (the file still has the same size) but we gain knowledge that the file pretends to be hdcd and have options to do smth with it or not do smth with it (and the cost is minimal- the resources to decode it to 24 bits).
I do not want to exclude antyhing from being seen as HDCD - I want to have option to decide what to do with it - halve or not. Excluding disables everything.

Quote from: Case on
There is a slight logic error when you say that component setting shouldn't affect decoded bit depth. That is a direct result of the loudness halving. If you think that allowing user to configure it is a mistake, why then are you asking for more loudness halving options?
You need to remember that if bit depth is 17-bits, it just means 16-bits that has had its loudness halved. And that means it's a fake HDCD. Treating these as anything other than normal tracks is in my opinion nonsensical.
I did not know that the 17th bit is the result of lowering the volume - I thought that those additional bits are always there in the file (just packed).
I agree with you that sonically there is no point in decoding such fakes but it makes huge difference to me:
- having an option to see if such a file reports itself as HDCD (I use "HDCD (inactive)" phrase in my display) but not halving it or
- not seeing if it reports itself as HDCD thus not being able to do anything with it.
As a side note - I agree with @Defender that TF is also an informative feature (even if we can't decode it) - and just beacuse I use "always halve" and do not use "exclude" I have no problem with "exclude when there is no PE or LLE". But when used...it would show all files with TF as nonHDCD.
By the way - if 17th bit comes from halving how should I understand such cases when I see PE=yes but the file reports itself as 17bit (not 24) with TPS?
PS. I have the same logic (or "unlogicness") when it comes to the "decoded_*" formulas. Those work really well with sacd_input - ex. they provide info that DSD has been decoded to DSD or has been decoded to PCM as both "decoded_samplerate" and "decoded_bitspersample" are not constant and show either 2,8/1 or PCMrate/64 depending on the output option used. We also have "decoded_channels" and "decoded_channel_mask" which always show proper values for DSD. When playing HDCD only "decoded_bitspersample" shows 24 bits and the rest of the fields stay empty which..looks strange/not informative/not pretty. I know that the empty field means that ex. "decoded_samplerate"="samplerate" but what is wrong in explicitly showing it?