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 -
"titleformat" doesn't seem to work anymore.
Has the format changed?
In previous versions it was something like "%__hdcd%".
As @Defender already replied, I changed the logic. The old fields are all still present. I know people want to see HDCD track is HDCD track throughout the playback. foobar2000 component doesn't need to be as limited as a hardware player that doesn't work per-track but by constant stream of data.
If a track is considered HDCD the %__hdcd% info field will stay on and instead temporary hdcd code disappearances can be tracked with %__hdcd_active%.
92
General - (fb2k) / Re: Title formatting/syntax for proper bitdepth
Last post by Case -
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?

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.
93
General - (fb2k) / Re: Title formatting/syntax for proper bitdepth
Last post by Case -
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.
94
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?
97
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.
98
3rd Party Plugins - (fb2k) / Re: foo_vis_vumeter
Last post by oops -
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.