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: HDCD Decoder (Read 327089 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: HDCD Decoder

Reply #450
So is this plugin unreliable?

Re: HDCD Decoder

Reply #451
And this is really difficult to fix, since it would require a full CD image file, and a scanner that can be told to check the beginning of the image file, before it seeks to the specified offset for the CUE sheet.
No, the error is not dependent upon images or cuesheets. I did not use any cuesheet to create any pregap.

See the attachment. The situation is the following. For a single file - no cuesheets! -
* foo_hdcd fails to detect the low level gain at the beginning of the track, and
* the very same signal is detected if it is not at the beginning.

Re: HDCD Decoder

Reply #452
And as I said, the HDCD signaling in that CD is only in the beginning of the first track. The entire remainder of the album is devoid of signaling information. There is no way to detect it easily in other tracks, short of having a tag report that something should be applied to the tracks themselves.

 

Re: HDCD Decoder

Reply #453
The problem is not "in other tracks". The problem is that it does not detect the gain where there is supposed to be a gain.
(Because it is supposed to apply a -4 dB at the beginning of the first track, right?)

This is why I don't understand what you mean about "image file", "offset" and "CUE sheet". foo_hdcd reports 0.0 dB when - according to "everything else" - receiving a signal to apply -4 dB.

Re: HDCD Decoder

Reply #454
How many HDCD signal packets are encoded in the first track? My component ignores any files with less than two consecutive packets.

Re: HDCD Decoder

Reply #455
@kode54: does it ignore the first ten seconds?!? The attachment can indicate so.

How many HDCD signal packets are encoded in the first track?
How can I tell? New upload ...

My component ignores any files with less than two consecutive packets.
That cannot be the full explanation: when I repeat the first 30 frames sufficiently many times, it kicks in. If so, it would have to be the very last and very first moment of those thirty frames - and even then, it should have kicked in when only two were merged.

Attached are three files: For the file Tool10xfirst1sec.flac, I extracted the first second (using ffmpeg -to 1) and concatenated ten copies of the audio together. I get no HDCD. For Tool11xfirst1sec.flac, I concatenated eleven - and then it applies gain! For Tool10xfirst1.01sec.flac, I extracted the first 1.01 seconds and concatenated ten copies - that is 10.1 seconds, and now you can check what it says about that :-o


Re: HDCD Decoder

Reply #457
Ah, my bad. It's not two consecutive chunks. It needs to still be enabled after a minimum of two chunks of audio and ten seconds.

Note that in a real HDCD player, after the requisite timer from a single packet counts down, the HDCD effect shuts off.

Re: HDCD Decoder

Reply #458
Ah, my bad. It's not two consecutive chunks. It needs to still be enabled after a minimum of two chunks of audio and ten seconds.

There are enough HDCD packets throughout the entire album for foo_hdcd to report all tracks as HDCD.
The problem is that foo_hdcd does not apply the -4 dB gain, apparently because it ignores the first seconds.

Note that in a real HDCD player, after the requisite timer from a single packet counts down, the HDCD effect shuts off.

In a real HDCD player, HDCD will be turned off after ten (?) seconds of HDCD inactivity.
foo_hdcd seems not to be turned on until ten seconds of activity.

Looks like a bug to me?

(Why not let foo_hdcd observe a HDCD tag to be set to "yes"?)


There is an issue, of course: since mastering can get offsets and track boundaries wrong, then ripping a compilation album could get the last few samples (with HDCD) track x at the beginning of track y.
A real HDCD DAC will keep HDCD on until timeout. (It will even do so if you play a non-HDCD track right after a HDCD track in a playlist - unwanted behaviour, sure.)
A software player could look ahead a few seconds. If nothing - reset. If something - keep on.

Re: HDCD Decoder

Reply #459
Gain is not applied globally. Gain is reported by every packet, and last I checked that album, it has a gain of -4 for about a second, then ramps up to 0 for the remainder of the album.

Re: HDCD Decoder

Reply #460
Gain is not applied globally. Gain is reported by every packet, and last I checked that album, it has a gain of -4 for about a second, then ramps up to 0 for the remainder of the album.

So why does foo_hdcd fail to apply that -4 dB gain for about that second?  (I know that gain is reported by the packet, that is not the question.)

If I concatenate ten copies of that second, it fails to identify it as HDCD at all.
If I concatenate ten copies of 1.01 seconds, it identifies it as HDCD, but does not see the gain.
If I concatenate eleven copies of that second ... wow, it sees that there is -4 dB gain there. But such a packet is in every one of the ten copies it fails to recognize.

Re: HDCD Decoder

Reply #461
Clearly, the fade is shorter than the requisite 10 seconds my decoder needs to warm up. Maybe I should eliminate the warm up period, so we can get a lot more false positives.

Re: HDCD Decoder

Reply #462
Clearly, the fade is shorter than the requisite 10 seconds my decoder needs to warm up. Maybe I should eliminate the warm up period, so we can get a lot more false positives.
How many false positives do you think you will get among those tracks that foo_hdcd actually recognizes as HDCD?
foo_hdcd does indeed recognize the track - from way before 00:01.00 it can tell me it is a HDCD - it just throws away the gain instead of applying it.

(How would this work with loud track transitions? Applying +6 dB at the end of track N and instantly dropping it at the track boundary even though the entire track N+1 has HDCD packets?)

Re: HDCD Decoder

Reply #463
As I said, it detects it at all, but it doesn't do any processing unless it detects it for a full 10 seconds and a minimum of two audio_chunks from the input.

Re: HDCD Decoder

Reply #464
As I said, it detects it at all, but it doesn't do any processing unless it detects it for a full 10 seconds and a minimum of two audio_chunks from the input.
So you are saying that there is not as much as ten seconds of HDCD packets in that track?

Re: HDCD Decoder

Reply #465
I don't believe so. I could check further, though. Really, the only way to check for multiple consecutive packets at all, is to process in shorter intervals, and regularly check for the interval counter increasing again, as it is reset to a full second again when a new packet is detected.

Pull requests are welcome, in case anyone else knows a neat and easy way to do this, and doesn't want to wait for me.

Re: HDCD Decoder

Reply #466
(Why not let foo_hdcd observe a HDCD tag to be set to "yes"?)
I'd like to use HDCD=yes on the few HDCDs to eliminate lag upon opening and also seeking in all 44,100/16-bit files, among which the overwhelming majority are not HDCD. Adding "no" to the entire collection is excessive.

Re: HDCD Decoder

Reply #467
I have made more observations and found that the poor performance and lag on track change and seeking is connected to the running time of Foobar or perhaps amount of data played. If I leave Foobar2000 open overnight, idle, not playing, then play an HDCD track next day, it is slow. The mouse pointer freezes on track change. Only lossless CD-resolution tracks without the HDCD=no are affected. If I restart Foobar without making any changes (not the computer, just Foobar), the performance is ok. Why would this be?

Re: HDCD Decoder

Reply #468
Hi - would like to confirm 2 things please--

1.  is it still true that ReplayGain must be set to off for realtime decode with this plugin?
2.  in latest Foobar 1.4x beta, nothing is written to the console, but the bit depth column will switch from 16-->24 when the decoder is active during playback with an HDCD identified track?

thanks

Re: HDCD Decoder

Reply #469
1) No. ReplayGain is applied after this plugin decodes the signal.
2) Dynamically applied metadata will reflect the HDCD mode and its properties.

Re: HDCD Decoder

Reply #470
1) No. ReplayGain is applied after this plugin decodes the signal.
2) Dynamically applied metadata will reflect the HDCD mode and its properties.
Excuse me, will there be "FOO_INPUT_MQA" in the future?

Re: HDCD Decoder

Reply #471
Yeah, sure, I'll get right on that, as soon as there's a library for it that doesn't have an evil license. Last I checked, there's only one library, usually bundled with things like Tidal, and it requires that the audio go directly to a DAC, and not any digital output, or to any other process where the decoded data can be read or logged or processed further.

Re: HDCD Decoder

Reply #472
Yeah, sure, I'll get right on that, as soon as there's a library for it that doesn't have an evil license. Last I checked, there's only one library, usually bundled with things like Tidal, and it requires that the audio go directly to a DAC, and not any digital output, or to any other process where the decoded data can be read or logged or processed further.
About:http://www.2l.no/hires/index.html

Re: HDCD Decoder

Reply #473
Yeah, no, that doesn't look like a decoder library, it looks like a selection of sample media.

The HDCD decoder was reverse engineered from an existing player (Windows Media Player), it was not reverse engineered from simply having sample media.

Re: HDCD Decoder

Reply #474
@kode54:
I had another look at this and tried to catch a little bit of the code, although I do not speak C++

The big mistake is to discard 10 seconds of HDCD packets. Your component has a timer for when HDCD is turned ON after the FIRST packet.  Obviously that is not the same as what a HDCD DAC does: it has a timeout for when HDCD is to be turned OFF after the LAST packet.
Consequence: if full volume is reached by 10 seconds, your component will all for sudden boost the volume by 6 dB.  I had issues like that. 
The "easy" fix is to drop that count-up.  Do what a physical HDCD DAC would do: apply HDCD once valid HDCD is found.

Also, an "easy" fix, as mentioned earlier: Honor a HDCD tag set to "yes": if so, assume that HDCD is activated throughout the track, period.


But we still have the issue of when to switch HDCD off. For physical CDs, a ten-seconds timeout will suffice for replacing a (HD)CD with a different CD and pressing Play.
File playback does not work that way - a track from the next (non-HDCD?) album will start immediately. 
Fix: HDCD should be reset when starting on a file from a different album

Then there is an issue for compilation CDs with both HDCD and non-HDCD tracks.  That issue is "unresolved" even for physical CDs, but potentially much worse for files that have appended the next track's pregap. Also, the CD write/rip offset issue means that samples could bleed over into the neighbouring track (previous or next). 
"Easy fix": the user can set the HDCD tag to "NO".
Feature request: scanner could report if HDCD packets are present only at the beginning or the end (2.1 seconds would cover appended "track N+1 index 0" and wrong offset).


As for Lateralus, you got a few things wrong (there are HDCD packets throughout the entire CD!), but the misimplementations are much more serious than the consequences for this particular release.