v17 DTS music playback from WavPack (.wv) files
#16
It's not about "random" noise .. it's about data altering which ends up in some "bits" the AVR recognizes as PCM and not as DTS.

Consider the following: User has set kodi volume to 75%. Kodi decodes wv lossless to float (float 32 bit), from here it multiplie every sample with 0.75. And from here it maps the data to a 24 bit or 16 bit Sink for output. What do you think you will hear?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#17
I think you are misunderstanding me. We are in agreement. Are you still drunk from new years?Smile
Reply
#18
Nope :-). But wanted to emphasize by repeating things. Cause I am 100% sure this thread will be highjacked by another audiophile guy once upon a time not understanding what is going on.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#19
I am with @fritsch on this one. It looks like the AVR decodes this by "accident". I checked the channel status bit on the analyzer and it is set to "linear PCM samples" when you play the wavpack file. It is set to "other than linear PCM" for the WAV file. When I tested this with my Denon X6200W AVR, it did play the wavpack file correctly in DTS, but that was the first time. Now, it is not playing it at all and I didn't change a thing. (Tested with LibreELEC Milhouse build #1230 on Intel Haswell).

Here are two samples for anyone who wants to try this out (must like Mannheim Steamroller Smile)

DTS WAV
DTS Wavpack (MediaInfo detects this as 2 channel PCM)

I also have to say that both the formats do not play in Android (nVIDIA Shield).
Reply
#20
(2017-01-02, 22:45)wesk05 Wrote: I am with @fritsch on this one. It looks like the AVR decodes this by "accident". I checked the channel status bit on the analyzer and it is set to "linear PCM samples" when you play the wavpack file. It is set to "other than linear PCM" for the WAV file. When I tested this with my Denon X6200W AVR, it did play the wavpack file correctly in DTS, but that was the first time. Now, it is not playing it at all and I didn't change a thing. (Tested with LibreELEC Milhouse build #1230 on Intel Haswell).

Here are two samples for anyone who wants to try this out (must like Mannheim Steamroller Smile)

DTS WAV
DTS Wavpack (MediaInfo detects this as 2 channel PCM)

I also have to say that both the formats do not play in Android (nVIDIA Shield).

For the shield it's sadly clear :-( Float sink 2 channels :p - typical mixer. For DTS wav kodi will detect DTS and open the PT sink. You can easily verify that by pressing volume up / down. For the wav kodi will block it - for the other one, take great care :-) Ah and shield cannot play DTS 44.1 khz - with 48 khz it will work, their Packer is broken (on droid RAW api they pack - not we).
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#21
(2017-01-02, 22:51)fritsch Wrote: For the shield it's sadly clear :-( Float sink 2 channels :p - typical mixer. For DTS kodi will detect DTS and open the PT sink. You can easily verify that by pressing volume up / down. For the wav kodi will block it - for the other one, take great care :-) Ah and shield cannot play DTS 44.1 khz - with 48 khz it will work, their Packer is broken (on droid RAW api they pack - not we).
Yep! I already experienced it when I had it connected to the analyzer. With the AVR, wavpack now plays in silence (it is detected as 2 channel DTS). Let me see whether I have any 48kHz DTS music files.
Reply
#22
AVRs do not decode this "by accident", they must differentiate between say pcm/dts/dd so they analyze the incoming stream. (Doesn't Kodi have to do this with wav files? To determine if the wav is really a wav or a frame packed dd or dts file? if so why don't we send all 2 channel pcm through this analyzer after decoding from their respective formats?) This will always take precedence regardless what the bit flag is set to.
Reply
#23
(2017-01-03, 00:09)Soli Wrote: AVRs do not decode this "by accident", they must differentiate between say pcm/dts/dd so they analyze the incoming stream. (Doesn't Kodi have to do this with wav files? To determine if the wav is really a wav or a frame packed dd or dts file?) This will always take precedence regardless what the bit flag is set to.

You do need to read up on IEC 60958-1,3 and IEC 61937- 1,2,3,5,9 sepcs.

I just mentioned what the channel status bits 0 & 1 are set to when playing the two different files. AVRs do no not "analyze" streams. They get the information from audio InfoFrame and Channel Status Bits.
Reply
#24
Nah. It's not an accident that all AVRs since the Laserdisc ages will properly decode AC3 (and DTS for that matter, later on) regardless of the bit flag. They even released ac3 and dts compact discs they you were meant to playback through your normal cd player, only you had to use a toslink/coaxial cable to your avr. These sent the stream as normal 2 channel linear pcm, even though they weren't.
Reply
#25
(2017-01-03, 00:18)Soli Wrote: Nah. It's not an accident that all AVRs since the Laserdisc ages will properly decode AC3 (and DTS for that matter, later on) regardless of the bit flag. They even released ac3 and dts compact discs they you were meant to playback through your normal cd player, only you had to use a toslink/coaxial cable to your avr. These sent the stream as normal 2 channel linear pcm, even though they weren't.
My humble suggestion to you is to read the IEC specs and you will have a better understanding of the "bits" and "flags" that you mention.
Reply
#26
I humble suggest that you stop your humble suggestions and start talking like a normal person.

I read up on those specs over 10 years ago, and read up on general s/pdif 20 years ago when people were still using scart. The AVRs that predated iec61937 by 10 years didn't care about that bitstream flag, and they still don't. It's not an accident AVRs decode bitstream content even though they stream is flagged as linear pcm. This fact wont change, no matter how much you (or I) recite a standard that was made as a guideline to a 2 decade old technology.
Reply
#27
(2017-01-03, 00:56)Soli Wrote: I humble suggest that you stop your humble suggestions and start talking like a normal person.

I read up on those specs over 10 years ago, and read up on general s/pdif 20 years ago when people were still using scart. The AVRs that predated iec61937 by 10 years didn't care about that bitstream flag, and they still don't. It's not an accident AVRs decode bitstream content even though they stream is flagged as linear pcm. This fact wont change, no matter how much you (or I) recite a standard that was made as a guideline to a 2 decade old technology.

Then you have not read IEC 60958-1 Annex D or IEC 61937-1 Annex A or 61937-2 Table 2. I was going to upload those, but it doesn't look like you believe in specs. Also, I can only discuss about things that are from this century.
Reply
#28
I humbly suggest that you stop worry what I may or may have not read. Instead, argue your case properly, and not just reference sections from a pdf. What if lawyers did this in court?

Let's see what IEC 60958-1 Annex D is: It's not a spec, it's purely (pragmatic) information.

lS/iEC 60958-1:2004
Annex D
(informative)
Transmission of CD data other than linear PCM audio

This standard ailows the interface to carry data related to computer software or signals coded using non-linear PCM and the format specification for these applications is not part of fhis standard. The channel status Bit 1 of Byte O indicates whether the data is linear PCM or not, However, some CD applications currently set this Bit 1=“0 as meaning linear PCM data, while the actual data is not linear PCM but compressed audio data. Such applications do not conform to the IEC 60958 series.

Current data processing equipment such as computers and games machines have a CD-ROM drive and sometimes a IEC 60958 series interface, so there is a possibility of non-linear PCM data output that is dependent on the application software. Therefore, all equipment and applications should respect the channel status definitions in this standard to prevent unexpected behaviour in the decoder.

Consideration is required for applications that, for historic accordance with IEC 60958 with respect to channel status bit 1. level of noise being generated by the conversion of this signal data. Such noise might damage hearing or equipment.

-------------------

The "consideration" the manufacturers took was that the AVRs didn't strictly look at the channel staus bit, but actually the pcm frames itself and this would precede the channel status bit. This would protect the consumers equipment and hearing and as a result save the manufacturers for billions in law suits, warranties etc etc. It's not an "accident" that all AVR's do this, and besides: by the fact that all AVRs do this makes it's safe to say it's by design and/or choice.

..and don't know why you can only discuss things from this century, but fact is AVRs were doing this long before this century.

Now, please argue why you think that it's an "accident" that *your* AVR decodes compressed audio from a S/Pdif stream even though the channel status bit is set to linear pcm? And please explain why the hell this Annex D has anything with this being an "accident" or not in the first place, and why you think I haven't read up on it.
Reply
#29
Besides the technical details ... I hope no one will ever listen to such a file via headphones ...
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#30
How did I create the .wv files: I had those tracks as .waw and simply converted them with dBpoweramp into .wv. The only reason for doing this was to be able to tag them properly with Mp3tag, like the other .flac and (some) .mp3 music files I have, and have them included in the music library.

Playback: I have always controlled the volume on the AVR, never used the Kodi volume controls (always at full volume). And have always used WASAPI as output device, with Output Configuration set to "Best match" (have also HiRes .flac files). The AVR is set to Pure Direct input (always, irrespective of the kind of file I'm playing) so, I believe, Soli is right when saying that it recognizes the DTS stream and decodes it accordingly. Out of curiosity I tried changing the volume in Kodi (what fritsch suggested) and the sound did indeed stop. I did not hear any noise, though, was just silent. Interestingly, pressing the "+" button (max volume again) the sound came back and was normal (multi-channel), probably because at max volume there's no internal processing involved.

Here are the first 3 tracks of Aero:
https://www.dropbox.com/s/lzqp1mpq86su9n...20.wv?dl=0
https://www.dropbox.com/s/f6d54gnzjtdzbf...01.wv?dl=0
https://www.dropbox.com/s/qh7w6mc5zauw04...02.wv?dl=0
Reply



Logout Mark Read Team Forum Stats Members Help
DTS music playback from WavPack (.wv) files0
This forum uses Lukasz Tkacz MyBB addons.