Skip to main content ↑ ↓
Topic: HDCD Decoder (Read 213966 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 –
Quote from: kode54 on
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.

Quote from: kode54 on
How many HDCD signal packets are encoded in the first track?
How can I tell? New upload ...

Quote from: kode54 on
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 –
Quote from: kode54 on
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.

Quote from: kode54 on
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 –
Quote from: kode54 on
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 –
Quote from: kode54 on
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 –
Quote from: kode54 on
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 –
Quote from: Porcus on
(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?
 
SimplePortal 1.0.0 RC1 © 2008-2018