Popular Memory of Vinyl Records Probably a Shifting Memory

One phenomenon known in Psychology is, that as the years pass, memories which we have of a same thing that once happened, will change, so that, 10 or 20 years later, it becomes hard to trust those memories.

A modern phenomenon exists, by which many Baby-Boomers tend to recall their old vinyl records as having had better sound, than so-called modern, digital sound. And in total I’d say this recollection is partially true and partially false.

When “digital sound” first became popular (in the early to mid- 1980s), it did so in the form of Audio CDs, the sound of which was uncompressed, 16-bit PCM sound, at a sample-rate of 44.1kHz. Depending on how expensive a person’s CD player actually was, I felt that the sound was quite good. But soon after that, PCs became popular, and many eager people were advised to transfer their recordings, which they still had on LPs, to their PCs, by way of the PCs’ built-in sound devices, and then to compress the recordings to MP3 Format for Archiving. And, a bit-rate which people might have used for the MP3 Files could have been, 128kbps. People had to compress the audio in some way, because early hard drives would not have had the capacity, to store a person’s collection of music, as uncompressed WAV or AIFF Files. Further, if the exercise had been, to burn uncompressed audio onto CD-Rs (from LPs), this would also have missed the point in some way. (:2)

What some people might be forgetting is the fact that many LPs which were re-recorded in this way, had strong sound defects before being transcribed, the most important of which was, frequent scratches. I think, the second-most-common sound defect in the LPs was, that unless the listener had a high-end turntable, with a neutrally counterweighted tonearm, and a calibrated spring that defined stylus force, if an LP was listened to many, many times, its higher-frequency sound content would actually become distorted, due to wear of the groove.

(Updated 3/02/2021, 18h05… )

Continue reading Popular Memory of Vinyl Records Probably a Shifting Memory

An observation about some purchased FLAC Files.

One of the ideas which I’ve blogged about often – a pet peeve of mine – is how lossy compression is not inaudible, although some people have claimed it is, and how its use degrades the final quality of modern, streamed or downloaded music.

And so if this is taken to be real for the moment, a question can rise as to what the modern methods are, to purchase High-Fidelity, Classical Music after all. One method could be, only to purchase Audio CDs that were mastered in the 1990s. But then, the eventual problem becomes, that even the best producers may not be mastering new recordings in that format anymore, in the year 2019. We may be able to purchase famous recordings made in the 1990s, but none from later, depending on what, exactly, our needs are. But, an alternative method exists to acquire such music today, especially to acquire the highest quality of Classical music recorded recently.

What people can do is to purchase and download the music in 16-bit, FLAC-compressed format. Ideally, this form of compression should not insert any flaws into the sound on its own. The sound could still be lacking in certain ways, but if it is, then this will be because the raw audio was flawed, before it was even compressed. By definition, lossless compression decompresses exactly to what was present, before the sound was compressed.

I have just taken part in such a transaction, and downloaded Gershwin’s Rhapsody In Blue, in 16-bit FLAC Format. But I made an interesting observation. The raw 16-bit audio at a sample-rate of 44.1kHz, would take up just over 1.4mbps. When I’ve undertaken to Flac-compress such recordings myself, I’ve never been able to achieve a ratio much better than 2:1. Hence, I should not be able to achieve bit-rates much lower than 700kbps. But the recording of Gershwin which I just downloaded, achieves 561kbps. This is a piece in which a piano and a clarinet feature most prominently, and, in this version, also some muted horns. And yet, the overall sound quality of the recording seems good. So what magic might be employed by the producers, to result in smaller FLAC Files?

(Updated 8/27/2019, 14h45 … )

Continue reading An observation about some purchased FLAC Files.

Deriving a workable entropy-encoding scheme, based on the official explanation of CABAC.

One of the subjects which I recently blogged about, is that when encoding video-streams, some Codecs use 8×8 sample Discrete Cosine Transforms, but as with many DCTs, the coefficients produced tend to be values, which would take up too much space to store, in a fixed-length format. And so a family of techniques which gets applied, is loosely referred to as ‘Entropy Encoding’, with the key idea being, that the Entropy Encoding used for compressed video, is different again, from the Entropy Encoding used for compressed audio. And the scheme used for video has as advantage, that the encoding itself is lossless. Apparently, there are two variants actually used with H.264-encoded videos, which some people group together as MPEG-4:

  1. An unspecified form of variable-length encoding,
  2. CABAC,

The latter of which promises better compression, at the cost of greater CPU-power required, both to encode and to decode. I’m going to focus on ‘CABAC’ in this posting. There is an official explanation for how CABAC works, which I will refer to. In order to understand my posting here, the reader will need to have read the documentation I just linked to.

From first impressions – yesterday evening was the first day on which I examined CABAC – I’d say that the official explanation contains an error. And I’ll explain why, by offering a version of Entropy-Encoding, which I know can work, based on the link above, but different from it:

  • Integers are meant to be encoded, that are “Binarized”.
  • The probability with which the first “Bin” has become (1) instead of (0) can be analyzed as described, resulting in a Context Model of one out of (0, 1, 2), as described.
  • The next four Bins may not have individual probabilities computed, only resulting in Context Models (3, 4, 5, 6) when they are (1) instead of (0), which override the Context Model that the first Bin would generate.
  • The resulting, one Context Model could be averaged over the previous Values.
  • Using As a Pair of values, the Context Model (from the previous values) which was just computed, And the (present) Integer Value, a look-up can take place in a 2-dimensional table, of which sequence of bits to use, to encode (both).
  • Because the decoder has chosen the integer value out of a known row in the same look-up table, it can also update the Context Model being used, so that future look-ups when decoding remain unambiguous.

The main problem I see with the official explanation is, that because up to 6 Context Models can be computed, each of which supposedly has its own probability, based on that, the lookup-table in which binary values (entropy encodings) are to be found, would effectively need to be a 6-dimensional table ! Officially, all the Context-Models found, have equal meaning. Software is much-more probable, which uses a 2D table, than software which uses a 6-dimensional table, although according to Theoretical Math, 6-dimensional tables are also possible.

But then, a property of Variable Length Coding which has been observed for some time, was that small integers, such as (0), (1) and (2), were assigned very short bit-sequences to be recognized, while larger integers, such as (16) or (17), were assigned recognizable bit-sequences, which would sometimes have been impractically long, and which resulted in poor compression, when the probability of the integer actually being (0), (1) or (2) decreased.

So, because we know that we can have at least one Context-Model, based on the actual, local probabilities, when the probabilities of very small integers become smaller, a series of entropy-encodings can be selected in the table, the bit-length of which can be made more-uniform, resulting in smaller encodings overall, than what straight Variable-Length Encoding would have generated, CABAC instead being adapted to probable, larger integers.

The fact will remain, that the smaller integers will require fewer bits to encode, in general, than the larger integers. But when the smallest integers become very improbable, the bit-lengths for all the integers can be evened out. This will still result in longer streams overall, as larger integers become more-probable, but in shorter streams than the streams that would result, if the encodings for the smallest integers remained the shortest they could be.

Continue reading Deriving a workable entropy-encoding scheme, based on the official explanation of CABAC.

Web-Optimizing Lossless Images

One subject which has caught my interest in recent times, is how to publish lossless images on the Web – and of course, optimize memory-use.

It has been a kind of default setting on most of my desktop software, that I’ll either save images as JPEGs – that are lossy but offer excellent file-sizes – or as PNG-Format files – that are losssless, but that still offer much better file-sizes than utterly uncompressed .BMP-Files would offer. Yet, I might one day want even smaller file-sizes than what PNGs can offer, yet preserve the crisp exactitude required in, say, schematics.

The ideal solution to this problem would be, to publish the Web-embedded content directly in SVG-Files, which preserve exact curves literally at any level of magnification. But there are essentially two reasons fw this may not generally be feasible:

  1. The images need to be sourced as vector-images, not raster-images. There is no reasonable way to convert rasters into vector-graphics.
  2. There may be a lack of browser-support for SVG specifically. I know that up-to-date Firefox browsers have it, but when publishing Web-content, some consideration needs to be given to older or less-CPU-intensive browsers.

And so there seems to be an alternative which has re-emerged, but which has long been forgotten in the history of the Web, because originally, the emphasis was on reducing the file-size of photos. That alternative seems to exist in GIF-Images. But there is a basic concern which needs to be observed, when using them: The images need to be palletized, before they can be turned into GIFs – which some apps do automatically for the user when prompted to produce a GIF.

What this means is, that while quality photos have a minimum pixel-depth of either 24 or 32 Bits-Per-Pixel (‘BPP’), implying 8 Bits Per Channel, and while this gives us quality images, the set of colors needs to be reduced to a much-smaller set, in order for GIFs actually to become smaller in file-size, than what PNG-Files already exemplify. While 8-bit-palletized colors are possible, that offer 1/255 colors, my main interest would be in the 4-bit or the 1-bit pallets, that either offer the so-called ‘Web-optimized’ standard set of 16 colors, or that just offer either white or black pixels. And my interest in this format is due to the fact that the published images in question are either truly schematic, or what I would call quasi-schematic, i.e. schematic with colors.

What this means for me as a writer, is that I must open the images in question in GIMP, and change the ‘Image -> Mode’ to the Web-optimized, or the 1-bit Pallets, before I can ‘Export To GIF’, and when I do this, I take care to choose ‘Interlaced GIF’, to help browsers deal with the memory-consumption best.

In the case of a true 1-bpp schematic, the effect is almost lossless, as the example shown below has already occurred elsewhere in my blog, but appears as sharp here as the former, PNG-formatted variety appeared:

schem-1_8

In the case of a quasi-schematic, there is noticeable loss in quality, due to the reduction in color-accuracy, but a considerable reduction in file-size. The lossless, PNG-format example is this:

quasi-schem-1_1

While the smaller, GIF-format File would be this:

quasi-schem-1_9

There is some mention that for larger, more-complex schematics, GIFs take up too much memory. But when the image really has been large in the past, regardless of what I might like, I’ve been switching to JPEGs anyway.

There could be some controversy, as to whether this can be referred to as lossless in any way.

The answer to that would be, that this results in either 1 or 4 bit-planes, and that the transmission of each bit-plane will be without alteration of any kind – i.e., lossless. But there will be the mentioned loss in color-accuracy, when converting the original pixel-values to the simplified colors – i.e. lossy.

Continue reading Web-Optimizing Lossless Images