Lies about vinyl vs digital

[mansr]

22 minutes ago, davide256 said:

Reminds me  of dialup modem days when we used data compression modulation schemes to get 56khz rates out of lines that had a physical limit of 2.4khz.... amazing how much of raw data is just repeated 1's and 0's.

Traditional phone lines have an analogue bandwidth of about 4 kHz. The V.34 modem standard provides data rates up to 33.6 kbps over such a channel. The V.90 standard increased downstream rates to 56 kbps by tying directly into the digital network. On the fly compression could increase the effective data rate significantly, depending on the content. Text compresses well, JPEG images not so much since they are already compressed.

[mansr]

35 minutes ago, lucretius said:

I think the "perceptual" is a reference to MQA -- which Bob says is perceptually lossless.

That's a bit of newspeak meant to confuse the uninformed. The proper term is "psychoacoustically transparent."

[sandyk]

7 minutes ago, fas42 said:

Just be aware - unless Foobar has significantly changed in the meantime - that the ABX module is useless for comparing this sort of thing;

 Agreed that Foobar ABX module is nigh on useless for comparing this kind of thing, but with these 2 samples the differences were such that I only needed to listen to them without using it's comparator.

 An E.E. friend of mine built his own comparator using relay switching etc.

[fas42]

5 hours ago, Paul R said:

I first suspected the cart, but if anything - it is something to do with the recording setup. What, given the only change needed to produce that bit of oddness is the recording sample rate, I do not know. Cables are impedance matched of course correct resistors in them, correctly grounded, etc. Channel-D built these cables, but same result with home built cables. 

 

It it could be something inherent with the sample rate but I cannot imagine what, and am very unwilling to go down that road. Operator Error is much more likely. 

 

Okay Frank - this sounds like you believe this is a problem in your kinda world. Where in specific, would you look?  

 

 

 

 

I can't imagine that it's anything to do with the rig - unless the cartridge has warming up behaviour. I once heard a very ambitious setup, with a Benz catridge, change very considerably over an hour - the owner accepted that the cartridge had this characteristic - I would have a hard time doing so!

 

More likely that there is a setting somewhere in your recording chain, that is effectively giving this result. Which may be buried deep inside some menu, and you have to know it's there. Just to confirm that it is the recording setup, I would feed in say a white noise track from the analogue outputs of a CD player and record that at both 44.1 and 192k - and see what shows. If there is still a tilt, then you need to go over every settings area with a fine tooth comb.

[Paul R]

53 minutes ago, mansr said:

Lossless compression reduces the data size but not the information content.

 

Well, to be really picky, lossless compression is technically just a class of algorithms that compress a dataset in such a way as to allow perfect recovery of the data.  

 

While the data is compressed, it fits in a smaller storage allocation. The information carried by the data is obscured until the data is un-compressed and restored to its original size.  So effectively in a data processing design, the data size has never changed, only been mutated into a different and less accessible format with a smaller static storage requirement. 

 

I used to have trouble with a few of my engineers thinking that they could compress the data and didn't have to decompress it to actually use it. Those unpleasant incidents made me sensitive to language usage, at least in design documents.

 

Which this is not, so I have no problem with what anyone wants to call it, as long as everyone understands what is being talked about. 

 

[Paul R]

8 minutes ago, fas42 said:

 

I can't imagine that it's anything to do with the rig - unless the cartridge has warming up behaviour. I once heard a very ambitious setup, with a Benz catridge, change very considerably over an hour - the owner accepted that the cartridge had this characteristic - I would have a hard time doing so!

 

More likely that there is a setting somewhere in your recording chain, that is effectively giving this result. Which may be buried deep inside some menu, and you have to know it's there. Just to confirm that it is the recording setup, I would feed in say a white noise track from the analogue outputs of a CD player and record that at both 44.1 and 192k - and see what shows. If there is still a tilt, then you need to go over every settings area with a fine tooth comb.

 

Well, I can't imagine a recording setting that would cause that, and so consistently! 

 

I am starting to narrow down on the RIAA equalization.  The raw information on the record has the treble boosted and the bass trimmed back. It seems like RIAA equalization, at least digitally, may be sensitive to the sample rate. Doesn't explain why it occurred with analog RIAA compensation though. 

 

-Paul

 

 

[mansr]

7 minutes ago, Paul R said:

Well, to be really picky, lossless compression is technically just a class of algorithms that compress a dataset in such a way as to allow perfect recovery of the data.

You seem to be equating data with information. What do you call a specific bit sequence disregarding its information content?

[Paul R]

Usually a data set, or sample.   In some situations, a data stream, buffer, etc. 

 

Information is data, just put into a meaningful context. Ergo, the information in a compressed data set is obscured. 

[lucretius]

1 hour ago, mansr said:

Traditional phone lines have an analogue bandwidth of about 4 kHz. The V.34 modem standard provides data rates up to 33.6 kbps over such a channel. The V.90 standard increased downstream rates to 56 kbps by tying directly into the digital network.

 

I think I still have a USR V.90 modem in my basement.

[lucretius]

49 minutes ago, mansr said:

You seem to be equating data with information. What do you call a specific bit sequence disregarding its information content?

 

delete

[lucretius]

44 minutes ago, Paul R said:

Usually a data set, or sample.   In some situations, a data stream, buffer, etc. 

 

Information is data, just put into a meaningful context. Ergo, the information in a compressed data set is obscured. 

 

Data set or dataset is problematic; it can mean so many different things.

[Rexp]

9 hours ago, esldude said:

I've already said I thought the first down sampled version sounded different. Fas42 has shown the FR is different. No mystery. I didn't find my resample to sound different. Did you try it?

I'm comparing your 16/44 wav downsample to Pauls 24/192 aiff, did you make a mistake when downsampling? 

[esldude]

12 minutes ago, Rexp said:

I'm comparing your 16/44 wav downsample to Pauls 24/192 aiff, did you make a mistake when downsampling? 

No.  Here is a screen shot comparing the downsampling I did to Paul's original.  Upper is the original, and lower (with the completely flat line) is the difference after subtracting the downsample from the original.  The FFT shows the only differences above - 145 db are above 20khz and the level of those is very low itself. 

 

So why do you think there was a mistake?

 

[sandyk]

15 minutes ago, Rexp said:

I'm comparing your 16/44 wav downsample to Pauls 24/192 aiff, did you make a mistake when downsampling? 

Dennis

 In your post 1380 you said that you didn't hear a difference after level matching. .

 Those who did hear differences would most certainly have done relatively close  level matching.

 

Alex

[Ralf11]

WoW!!

 

Now you're speculating about what unidentified people "would" have done!!!

[sandyk]

4 minutes ago, Ralf11 said:

WoW!!

 

Now you're speculating about what unidentified people "would" have done!!!

 

 Isn't it about time that you gave other forum members a bit of credit instead of your inane superfluous comments ?

[Doak]

14 minutes ago, sandyk said:

 

 Isn't it about time that you gave other forum members a bit of credit instead of your inane superfluous comments ?

Simply amazing, to me, how my recently blocking just a handful of “local correspondents” has incredibly simplified/streamlined the time I spent here. 

[Paul R]

Comon guys - let's stop sniping - please?  

-Paul 

 

[Paul R]

2 hours ago, lucretius said:

 

Data set or dataset is problematic; it can mean so many different things.

 

A set to me is a related group of items, and an ordered group of bits seems to fit the picture. 

When you apply more structure to them, you can extract more meaning.

 

If the bits represent a toggle event, then you can count the times a switch was toggled. That becomes information.  But without more structure, you can't really draw a lot more. For instance, if the bits were all part of a bitstream, with known and stable timing, you could reconstruct the timing between toggles. More information. 

 

If they are organized into bytes or words of some specific length, and you know what order was imposed upon them, you can draw even more information. If they are binary instructions and you know the binary/assembler language for the target machine, you can decode the instructions. An even higher level of abstraction. 

 

But the absolute bits remain the same. Just data, perhaps with meaning, perhaps not. I am not sure I can think of a better word than dataset, though I can see how that would be confusing at a much higher level. I think it works in context though.  

 

Sure open to better suggestions.  

 

 

Yours, 

-Paul 

 

 

 

[Paul R]

51 minutes ago, sandyk said:

Dennis

 In your post 1380 you said that you didn't hear a difference after level matching. .

 Those who did hear differences would most certainly have done relatively close  level matching.

 

Alex

 

You missed that Dennis was referring to the second set of samples I uploaded. The first set was mistakenly run through some processing not designed for it, and that processing really jacked it up big time.  The second set of samples is the original recording at 192k and a second recording at 44.1K.  They are much more alike to be honest.

 

You can identify the completely uncorrected version by the pops and crackles. 

 

Frank identified that there is slightly higher levels in the 44.1k sample than in the 192k sample. Not sure of the answer why at this point.

 

Yours,

-Paul 

 

 

[sandyk]

10 minutes ago, Paul R said:

 

You missed that Dennis was referring to the second set of samples I uploaded. The first set was mistakenly run through some processing not designed for it, and that processing really jacked it up big time.  The second set of samples is the original recording at 192k and a second recording at 44.1K.  They are much more alike to be honest.

 

You can identify the completely uncorrected version by the pops and crackles. 

 

Frank identified that there is slightly higher levels in the 44.1k sample than in the 192k sample. Not sure of the answer why at this point.

 

Yours,

-Paul 

 

 

Paul

 To save searching through quite a few pages againcan you please give me the new links ?

Alex

[Paul R]

4 minutes ago, sandyk said:

Paul

 To save searching through quite a few pages againcan you please give me the new links ?

Alex

 

Sure, I thought you had them because I put them on Dropbox.  Sorry!  -Paul 

 

https://www.dropbox.com/s/9uecebg1wc0rjcf/Chopin* - Alberto Mozzati.zip?dl=0

 

 

[Rexp]

26 minutes ago, Paul R said:

 

You missed that Dennis was referring to the second set of samples I uploaded. The first set was mistakenly run through some processing not designed for it, and that processing really jacked it up big time.  The second set of samples is the original recording at 192k and a second recording at 44.1K.  They are much more alike to be honest.

 

You can identify the completely uncorrected version by the pops and crackles. 

 

Frank identified that there is slightly higher levels in the 44.1k sample than in the 192k sample. Not sure of the answer why at this point.

 

Yours,

-Paul 

 

 

No Paul, we are referring to your original 24/192 aiff v esitudes 16/44 downsample of the same. Frank confused matters. Your recording sounds great, the other sounds off. 

[Rexp]

20 minutes ago, Rexp said:

No Paul, we are referring to your original 24/192 aiff v esitudes 16/44 downsample of the same. Frank confused matters. Your recording sounds great, the other sounds off. 

Here is your 24/192 (aiff) recording:

https://audiophilestyle.com/applications/core/interface/file/attachment.php?id=56129

 

 

And here is the same, down sampled to 16/44.1 (wav):

https://send.firefox.com/download/1af2ef1d48ecda79/#792ya3sGL2JKAH0pFhJYKQ

 

The downsample sounds bad doesn't it, why? 

[sandyk]

50 minutes ago, Paul R said:

 

Sure, I thought you had them because I put them on Dropbox.  Sorry!  -Paul 

 

https://www.dropbox.com/s/9uecebg1wc0rjcf/Chopin* - Alberto Mozzati.zip?dl=0

 

 

 Paul

 I stand by my comments about the differences , as the link that you gave me must have been the same as I used  before according to the attached.

Regards

Alex

 

; 17/05/2019 1:22:00 PM

b9a94cc8f4aac450fb21641eaf065c6d *__MACOSX\Chopin_ - Alberto Mozzati\._.DS_Store
eb5dfb32582c0dd7bf05f68cfe6ea7e5 *__MACOSX\Chopin_ - Alberto Mozzati\A Chopin Recital (44.1) (AIFF)\._Etude In G Flat Major, Op. 25, No. 9.aif
493acaf7e4c8142daba5c85c01848d96 *Chopin_ - Alberto Mozzati\.DS_Store
2308f5e31bdab3a87f0fc13eaef05fd4 *Chopin_ - Alberto Mozzati\A Chopin Recital (192) (AIFF)\Etude In G Flat Major, Op. 25, No. 9.aif
d868a99bedf36eeeeb26e5e468e3d282 *Chopin_ - Alberto Mozzati\A Chopin Recital (44.1) (AIFF)\Etude In G Flat Major, Op. 25, No. 9.aif

; 5 files hashed.
; Checksums generated by ExactFile 1.0.0.15
; http://www.exactfile.com
; 17/05/2019 1:23:09 PM

493acaf7e4c8142daba5c85c01848d96 *Chopin_ - Alberto Mozzati\.DS_Store
2308f5e31bdab3a87f0fc13eaef05fd4 *Chopin_ - Alberto Mozzati\A Chopin Recital (192) (AIFF)\Etude In G Flat Major, Op. 25, No. 9.aif
d868a99bedf36eeeeb26e5e468e3d282 *Chopin_ - Alberto Mozzati\A Chopin Recital (44.1) (AIFF)\Etude In G Flat Major, Op. 25, No. 9.aif
b9a94cc8f4aac450fb21641eaf065c6d *__MACOSX\Chopin_ - Alberto Mozzati\._.DS_Store
eb5dfb32582c0dd7bf05f68cfe6ea7e5 *__MACOSX\Chopin_ - Alberto Mozzati\A Chopin Recital (44.1) (AIFF)\._Etude In G Flat Major, Op. 25, No. 9.aif