Flac vs Wav audio quality

NO I am not saying that FLAC is rubbish.

You state that Neil's Pono is rubbish and say you would never use FLAC, so it seemed to me you were blaming FLAC rather than the Pono's electronics.

I have tried all sets of tests of WAV v FLAC and could not tell the difference.  I haven't tried AIFF but if it can support decent tagging and I can rip it (dbPowerAmp does) then I might give it a go.  But I would be very surprised if it sounded any better.

Trouble is though, how many download sites do AIFF?

Media file codec / format and (portable/embedded) player design are two completely different beasts. It's not right to confuse the two.

If a lossless media compression format taxes the computing power / power supply of an embedded player / decoder without affecting data integrity, it's up to the hardware designer IMHO to ameliorate the electrical effects upon sound quality first, then tune the software later as a last resort (as the hardware will likely remain fixed throughout the duration of the product's lifespan).

The software can change over the life of a product (with live, real-time updates), but it is strictly limited by the hardware in the user's environment.

Sorry Wat I got the posts mixed up, thinking yours was reply to my comment on the original.

Yup I think we are pretty much in agreement.  You know, I have to ask why does this crop up with boring regularity on this site?

DavidDener, not sure which sub thread you were referring to as this thread(s) has got a little confusing.. But I was not aware of anyone saying Ogg Vorbis Comments don't exist.. They absolutely do and are encoded as part of the Ogg Vorbis encoding chunk and are a constantly evolving set of type value pairs.. What doesn't exist in any recognised de facto way (well at least at 2007) is to incorporate comments in the Ogg container itself. Therefore unlike RIFF files such as AIFF and WAVE that store metadata using different chunk IDs seperate from the media data within the RIFF container, if you use the Ogg container, such as in Ogg Vorbis (as used by Spotify) or the FLAC container the meta data, ie the Vorbis Comments, are included as part of codec data itself.

I am not sure this is hugely relevant anyway, as it should be transparent to the user,  but I put it out there just in case somebody was trying to follow this..... Or correct me..

Simon

Understood, yes. There is (codec) support within FLAC for multiple images corresponding to cover art, leaflet pages, musician photos, etc., but this only makes sense iff you store an entire album as one FLAC file (using a cue sheet to delineate track index points, for example); otherwise, it is wasteful to associate storage-intensive album-level metadata within a single track above a certain maximum size.

Twenty years ago, it was not unusual to rip an entire CD as a single file; I suspect that we'll soon see that return as a best practice (specifically for the reasons mentioned above); I have less optimism for a universal music or media container than I did, say, four years ago....

I would also suggest that remote (linked) metadata (for binary assets such as leaflet images) may very well become the norm a la Spotify / Last.fm, rather than embedding extended metadata into the files themselves - we'll have to wait and see.

Ultimately, these are very much first-world problems (i.e., legacy media storage and tagging); it would not surprise me to see premium streaming services assume the primary digital audio role (uncompressed, high-res, or otherwise) in most high-performance systems in the future, as they largely have on the video side.

indeed, the hypertext idea might catch on someday and be used to create a World Wide Web of referable information on a large global network... Nah it will never catch on.  

IBM got carried away with themselves and rather than release a rock solid multitasking OS with the same interface decided everyone wanted a complicated buggy OO interface that made it feel anything but rock solid... Microsoft seized their chance and released Windows 3.0... The rest is history. 

Wow, I remember it the other way around (albeit from a 32 bit / pre-emptive multi threaded programming perspective, and for sure at 2.0 timescales when the war was over as you say). For me, the death knell for OS/2 was its ability to run multiple Win3.1 virtual machines, hence obviating the need for native applications. The OO interface rocked once it worked, and it was a decade before we got to see its like again... 

Regards and and all best wishes for 2015,

alan

ps - and apropos the thread... I just signed up for the 3-months for $9.99CDN deal on Spotify while on holiday and have been having fun poking around and listening to new and old stuff on my iPod (via headphones offline, or through analog out into my girlfriend's stereo here in Berlin). Like the new Pink Floyd; amazed to find Rainbow's in a Curved Air (thanks to Big Bill and other forum folks for the reminder) ... That last album eluded my hunting for about a decade when I was in school, so it is a pure delight to just have access to it so trivially. I will try the SU native play when I get back home, and do the demo month of Tidal as well (thru the Mac mini via Toslink).

Get a download of Ghosts I-IV, a great album by Nine Inch Nails which has separate artwork for each track.  But considering that we generally listen while only a small pic is displayed makes it not really worthwhile.

ps If you download the PDF to the album and have a large computer screen you can see the artworks in all its glory and it is very good.

Ya have to remember how big IBM were at the time.  Like most people in the IT industry at that time everything I did was related around IBM kit - they were 'all pervasive'.  Unfortunately they began to believe their own hype and released the MCA bus architecture at the same time as OS/2.

If you bought an IBM MCA PC you had to throw away all your plug in cards, which were very important at that time - eg Network Card, 3270 Terminal card, etc, this was a big business at that time.  I can remember Ethernet cards being full length (10"x4" approx.) and going for the best part of a grand.  Also at this time Compaq +others cocked a snoop at Big Blue and brought out EISA bus equipped PCs and the war began.

IBM's attitude was "We are right so the World will follow" but it didn't and the company that supplied the Nazis with the kit to manage the holocaust nearly went the same way.  But aspects like POS kept them afloat.

This was a fascinating time and the war ended without EISA or MCA winning when Intel started producing 486 & Pentium motherboards with Ethernet & modems in place and a new architecture called PCI that could sit alongside the old one.  War over.

By the time of it's demise OS/2 had become a powerful multi-tasking OS but (a) nobody understood what it was about (inc. IBM), and (b) there was virtually no software that could take advantage of it, because of (a).

A fascinating time, there were truly some weird and wonderful products about.  I can remember a full length IBM PC card that with a keypress combination turned your IBM machine into an Apple IIe.  Even your floppy disk became the lower capacity Apple drives.  Now is that wild or not?

Simon, David,

I am in complete agreement with this.  It also fits neatly with the principles of Big Data (doing a late join to the associated data), as then the album could be reissued with different 'packaging' without altering the primary data (i.e. the audio).

Thinking this through a bit more, every album has a bar code - which is a unique reference. So this could be extended to tracks and therefore perhaps downloads and streamed content.

Therefore the media file might have the very basic or rudimentary meta data, including the unique reference  and a single moderate or low res album/track art picture.

The unique code or reference could then point to a more complete meta data database - and there could be differing databases with different focuses but each using the ID as the index key.

I do wonder perhaps if the horse has already bolted on this one.

HNY 

Simon

Simon,

What an excellent idea.

I know someone who is employed by the standards organisation in this area, I'll contact him as they may be interested in promoting this use.

Heh - not only do I have the album (and have used it to test development of UPnP control points), but I know those guys peripherally (as we all grew up playing music in northeastern Ohio / NW PA in the mid-80s).

PDF handling (and inner sleeve / brochure artwork retrieval) is one of those action points that could be well-handled using a URI (external site or local storage)....

The ISRC code is stored in the extra 8 bits (PQ subcode) on the disc itself, and this data is used during the metadata retrieval process.

Referencing the remark regarding Disc-At-Once imaging of a CD to local storage, this process preserves the PQ subcode data, although digital audio extraction to PCM data file(s) is still required for playback. It is not an unprecedented component of the media ingestion process (especially on older music servers), though it does take longer.

But David - I don't think this info [ISRC code]  is made generally available when ripping is it - or if it is it will be limited to certain rippers - and if so which ones?

Certainly I don't see it with dBPoweramp and sometimes meta data is a little hit and miss.

But yes the ISRC is designated for every track for royalty purposes, however if not stored as metadata will not be present in a download, streamed or ripped file. It is stored as part of the CD-Audio infrastructure.

S

The ISRC code can be retrieved and set in dBpoweramp CD Ripper as a tag (Meta & ID Tag Options).

I've cleaned up this thread, where needed.  Personal insults are not wanted here.

Dave - I will have a look - and this should be uniquely set for every track yes?

The ISRC spans the entire release (album set, if you will).

When you think about it this has to be the case.  You can buy a box set which has a different album name from the original but dbPowerAmp still finds it OK.

The reason that metadata is a bit hit and miss in dbPowerAmp (or any other product come to that) is that the unique ref is a link to an external database (you know the ones I mean) and these are going to contain different data to some extent.  Not a lot of metadata stored on a CD, as far as I know!

Not only that we may have different requirements too.  We may want artists stored as "surname, forename" for example.

ISRC identifies (and hence spans) an entire 'recording' for rights purposes, it doesn't identify a product (that's done with a GS1 code).

This has has got me thinking and it has implications...

If a single recording of a work spans multiple disks, then all the disks could (should?) have single ISRC (and will have a new GS1 code each time it's packaged as a product)

If a box set has one or more disks that have individually been released previously (or may possibly be individually released later) then it will have multiple ISRCs; however it will still have only one GS1 code per product packaging.

A recording that is released into different marketing zones (for instance different countries) could retain the same ISRC, but be associated with different descriptive metadata. It will though have a different GS1 code.  This can also happen if the product is re-released into the same market

Still room for confusion here.

Perhaps the only way to reliably identify the metadata would come from the application of the principles of data analysis (i.e. via Codd's laws), so that each entity is identified individually.  Hence we then  precisely know of what entity each identifier is a property.

Dave, I note some of my discs don't apparently have an ISRC subcode, though many do, but appear to have a UPC code instead. This is purely a numeric string, not the alphanumeric that is the ISRC. Additionally there are some discs that have both UPC and ISRC and some older discs that have neither. Are these two competing index methods do you know?

Simon

UPC is the predecessor to GS1.

It defines a product.  It's relevant to product manufacturing and packaging, stock control, distribution, marketing, sales and retail tills.

They don't really compete as they identify different things.

Huge, Dave, I found the answer, I guess i haven't been the only one asking about the difference between UPC and ISRC

https://www.isrcmusiccodes.com/general-faq.html#02

That is:

ISRC refers to the track of the artist's recording, irrespective of medium.

UPC refers to the carrier of the track ie the entire album or CD and refers to that physical release.

thanks.

Therefore for a universal index key for a track it could require both! Especially if you have compilations of tracks :-)

Simon