Jump to content

Now that hard drive storage is dirt cheap, I'm converting...


Recommended Posts

I went through this process a few months back. Was boring but once done its great as everything is now in FLAC file format and available to me for use on my phone and other devices/components around the house.

Its also nice to have everyrthing in order, so while ripping my CDs I also entered them into Discogs so I had a proper live catalog.  I have around 800cd's reduced from over 2000. I am spewing I didnt do this when I had the full collection so at least I had the files. Oh well.  Havent put the LPs in discogs yet, thats another pile of work i'll get to one day.

 

To rip the CD's I used DB Poweramp.

No reason other than it seemed easy to use and I could direct the file to where I wanted and also choose level of compression, I use monkey media gold edition as it also has an app on my phone I can sync with very easily in a drag and drop scenario or via wifi - For the file size I chose uncompressed which might have been overkill but its done now.  It also found my album artwork or let me choose my own, and has a few side programs like a file converter which I found useful.

  • Like 1
Link to comment
Share on other sites



2 minutes ago, frednork said:

some say that flac files as they require more cpu power to extract are inferior to wav files so if space isnt a problem wav has less potential downside.

 

It's such a small amount, it really does not matter.  You can convert losslessly back and forth between the two formats, so again, it just doesn't matter from that point of view either.   flac just seems more modern to me, than .wav files. 

 

Just a note, there are still players out there that don't understand flac (my car for example) and so, conversion to .mp3 still happens from time to time, but it's one way only :)  I keep the flac originals.

  • Like 2
Link to comment
Share on other sites

30 minutes ago, Cafad said:

Damn, one more thing I now need to pay some attention to.  The list just keeps getting longer.

Goodbye simplicity, hello complication.

 

Have fun amigo.

  • Like 2
Link to comment
Share on other sites

24 minutes ago, aussievintage said:

 

It's such a small amount, it really does not matter.  You can convert losslessly back and forth between the two formats, so again, it just doesn't matter from that point of view either.   flac just seems more modern to me, than .wav files. 

 

Just a note, there are still players out there that don't understand flac (my car for example) and so, conversion to .mp3 still happens from time to time, but it's one way only :)  I keep the flac originals.

It may not matter to you, it does to others. I havent tested this myself.

Link to comment
Share on other sites

37 minutes ago, frednork said:

It may not matter to you, it does to others. I havent tested this myself.

Probably a leftover "problem" from back when cpu's were much less powerful and struggled with music.  These days, even a raspberry pi has power to spare.

  • Like 1
Link to comment
Share on other sites



I looked at this a while back. Someone please correct me if I am wrong, from memory .....

 

FLAC vs Wave : The content a.k.a music is the same (PCM encoded) it is only the container that differs. Metadata ( song, track, artist, composer etc) became important over time for many people and FLAC and Wave were both excellent compared to other formats. There are free programs and commercial programs that can edit Metadata. This helps with managing your library e.g some of my rips have 'Various Artists' as the artist name, so when I search for a band it can not find a match even though I have plenty of songs by that band.

 

There is a fair bit of angst and confusion around compression. The music samples can be compresses e.g MP3 (lossy compression). FLAC and WAVE can have their music samples uncompressed and it is usually the default setting for ripping programs. We are long past the days of compressing music to save HDD space. The file itself can be compressed (loss-less compression) I would not worry about this.

 

FLAC seems to be more portable / universally supported on products, but I have not really noticed this. I think iTunes may even play Wave.

 

If you do get stuck, there are programs that will convert between FLAC - WAVE so you will not have to re-rip you CD collection.

Link to comment
Share on other sites

2 minutes ago, Cruncher said:

I looked at this a while back. Someone please correct me if I am wrong, from memory .....

 

FLAC vs Wave : The content a.k.a music is the same (PCM encoded) it is only the container that differs. Metadata ( song, track, artist, composer etc) became important over time for many people and FLAC and Wave were both excellent compared to other formats. There are free programs and commercial programs that can edit Metadata. This helps with managing your library e.g some of my rips have 'Various Artists' as the artist name, so when I search for a band it can not find a match even though I have plenty of songs by that band.

 

There is a fair bit of angst and confusion around compression. The music samples can be compresses e.g MP3 (lossy compression). FLAC and WAVE can have their music samples uncompressed and it is usually the default setting for ripping programs. We are long past the days of compressing music to save HDD space. The file itself can be compressed (loss-less compression) I would not worry about this.

 

FLAC seems to be more portable / universally supported on products, but I have not really noticed this. I think iTunes may even play Wave.

 

If you do get stuck, there are programs that will convert between FLAC - WAVE so you will not have to re-rip you CD collection.

 

Pretty much as I understand it... 

 

except the default for flac I have often seen to be compression level 5.  Don't confuse this with lossy compression.  It is lossless, and very similar to the way a zip file is compressed.  Using less compression MAY make the file faster to decompress, but as I was saying, most processors these days romp it in with power to spare. 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

22 minutes ago, aussievintage said:

Probably a leftover "problem" from back when cpu's were much less powerful and struggled with music.  These days, even a raspberry pi has power to spare.

Nope, more like when trying to extract every ounce of sq out of any given setup. 

Link to comment
Share on other sites

Guest rmpfyf
55 minutes ago, aussievintage said:

Probably a leftover "problem" from back when cpu's were much less powerful and struggled with music.  These days, even a raspberry pi has power to spare.

It's audible whether I play it with an Atom or a 20-core Xeon. CPU power has very little to do with it.

 

FLAC is a better format for archiving. Metadata, CRC, compression. Unless you can't convert FLAC is infinitely preferable for making sure you've a good, reliable copy of your data.

 

Whatever is native to your end device is best for playback, as it means no extra work. WAV is often a good proxy for this though there are zero devices that'll take 16-bit WAV as a native format. It is closer. 

 

My main rig runs an Amanero USB interface, that's a 32-bit PCM interface. There's a palpable difference in converting as such pre playback.

Link to comment
Share on other sites

38 minutes ago, frednork said:

Nope, more like when trying to extract every ounce of sq out of any given setup. 

Doesn't work like that.  Having a cpu sit idle with nothing to do won't make sq better.

 

5 minutes ago, rmpfyf said:

It's audible whether I play it with an Atom or a 20-core Xeon. CPU power has very little to do with it.

Since it is exactly the same data, it's lossless remember, how can it sound different if the cpu is not having trouble processing it?

  • Like 4
Link to comment
Share on other sites



Guest rmpfyf
57 minutes ago, aussievintage said:

Since it is exactly the same data, it's lossless remember, how can it sound different if the cpu is not having trouble processing it?

'not having trouble' doesn't mean 'no latency'. Not how CPUs work.

Link to comment
Share on other sites

24 minutes ago, rmpfyf said:

'not having trouble' doesn't mean 'no latency'. Not how CPUs work.

piffle, it's the same data and it sounds exactly the same.  Anyone can prove it by simply playing both wav and flac versions of the same file.  The OP can decide for himself.

  • Like 1
Link to comment
Share on other sites

Guest rmpfyf
5 minutes ago, aussievintage said:

piffle, it's the same data and it sounds exactly the same.  Anyone can prove it by simply playing both wav and flac versions of the same file.  The OP can decide for himself.

 

Piffle yourself. 

 

Anyone playing it and getting no difference is winning. Anyone that can hear a difference can leverage it. That someone can or cannot hear it isn't a proxy argument for what happens at OS or CPU level. 

 

Offloading processing for lower CPU latency is around as old as computing, nothing new revolutionary or hidden about it. It's particularly relevant in modern CPUs owing for a number of reasons, mostly related to power consumption. The 'same data' argument has not a lot (ie. nothing) do to with this much. If your rig sounds identical with the same file played with any power supply, any CPU speed or C state, any amount of tasks running, any... thing as long as the data is the same, then good for you. Plenty of reasons to suggest there are differences in processing that audibly effect the output on a number of systems for various reasons though if for whatever reason it's all below your threshold of sensitivity then you're winning. I mean this sincerely.

 

My library is stored FLAC because it's a (far) better archive format. I don't generally playback FLAC for critical listening. Horses for courses.

Link to comment
Share on other sites

2 minutes ago, rmpfyf said:

 

Piffle yourself. 

 

Anyone playing it and getting no difference is winning. Anyone that can hear a difference can leverage it. That someone can or cannot hear it isn't a proxy argument for what happens at OS or CPU level. 

 

Offloading processing for lower CPU latency is around as old as computing, nothing new revolutionary or hidden about it. It's particularly relevant in modern CPUs owing for a number of reasons, mostly related to power consumption. The 'same data' argument has not a lot (ie. nothing) do to with this much. If your rig sounds identical with the same file played with any power supply, any CPU speed or C state, any amount of tasks running, any... thing as long as the data is the same, then good for you. Plenty of reasons to suggest there are differences in processing that audibly effect the output on a number of systems for various reasons though if for whatever reason it's all below your threshold of sensitivity then you're winning. I mean this sincerely.

 

My library is stored FLAC because it's a (far) better archive format. I don't generally playback FLAC for critical listening. Horses for courses.

  Why not just let the OP try it for themselves?

Link to comment
Share on other sites

Guest rmpfyf
6 minutes ago, aussievintage said:

  Why not just let the OP try it for themselves?

You missed the bit in what you've quoted where this is almost literally written... or the  many other posts on this forum by myself and many others many times?

 

9 minutes ago, rmpfyf said:

Plenty of reasons to suggest there are differences in processing that audibly effect the output on a number of systems for various reasons though if for whatever reason it's all below your threshold of sensitivity then you're winning. I mean this sincerely.

 

As stated before intended for the OP, @Cafad if you've interest consider converting the lot to FLAC - should your hard disk start feeling sad enough to much on your files, there's features in FLAC that will let you know if you've still got good copies. Can't do that with WAV.

Link to comment
Share on other sites



13 minutes ago, rmpfyf said:

You missed the bit in what you've quoted where this is almost literally written... or the  many other posts on this forum by myself and many others many times?

 

 

As stated before intended for the OP, @Cafad if you've interest consider converting the lot to FLAC - should your hard disk start feeling sad enough to much on your files, there's features in FLAC that will let you know if you've still got good copies. Can't do that with WAV.

I upvoted/liked  your post as  I do believe the OP must try it for themselves.  I believe they will decide flac is the best for them.

 

I do also believe your concerns/fears come from a previous era where we struggled for cpu power and circuits that handled musical data badly.  I have experienced some of the problems you speak of, but that was years ago.  I am delightfully amazed at how well modern cpus and associated support chipsets can handle stuff I previously thought was the realm of dedicated DSPs and expensive proprietory LSI chips . 

 

 

  • Like 1
Link to comment
Share on other sites

Guest rmpfyf
4 minutes ago, aussievintage said:

I upvoted/liked  your post as  I do believe the OP must try it for themselves.  I believe they will decide flac is the best for them.

It's been a long day. I owe you a beer. Apologies.

 

4 minutes ago, aussievintage said:

I do also believe your concerns/fears come from a previous era where we struggled for cpu power and circuits that handled musical data badly.  I have experienced some of the problems you speak of, but that was years ago.  I am delightfully amazed at how well modern cpus and associated support chipsets can handle stuff I previously thought was the realm of dedicated DSPs and expensive proprietory LSI chips . 

I do a bit of work in OS development, software development and the like. Have the good fortune to have a former chip developer at Intel as a close friend that indulges my various stupidities (including attempting audio) along with some actual 'real' work we collaborate on (which isn't audio). 

 

The process of playback (as in 'just' playback) is not net CPU intensive. Unless the conversions involve domain conversions (e.g. PCM>DSD and the like) then it's computationally not a lot at all... to the point I'm about to use a PC for 8-channel filtering at 192kHz and it won't really break a sweat, nor is it a beast of a machine (I'm hoping it doesn't **** itself occasionally and fry my speakers, but that's another story). 

 

The differences are most practically around task latency. Flac playback isn't enough to consistently boot a modern CPU into a C-state ('how much' of the CPU is used, in a coarse way) that's lowest-latency. Data is packetised so what we end up with (this is a gross oversimplication of what happens in practice) is intermittent periods where the CPU cycles between latency states that are high and low. Of concern to us, jitter. You could lock the C-states at lowest latency to minimise the effect (I do) though keeping the whole thing on all of the time generally isn't a plus (power consumption effects etc dominate). Remember, as the cycle-to-cycle latency changes, the CPU is still responsible for moving music through to the playback device. This doesn't change whether the CPU load is 0.8% or 80% for the same task.

 

Conversion to a native format effectively means removes the need to spool up intermittently... operation is temporally smoother.

 

The effect is (obviously) more obvious on systems that are core limited, that have very lightweight operating systems/runtime environments and (of course) in DAC implementations susceptible to an audible difference in upstream jitter. Beyond which the ears involved have to be able to discern things (response, acuity, speakers, room dynamics, etc... ) If one was running a full OS, frinstance, the differences would IMHO be small to negligible - music would be a sole OS task among a few hundred, many of which would be active.

Link to comment
Share on other sites

Hey Jeff, have a look at this. When the restrictions are eased Terry will be have a gtg.

Bring your digital and if I can, I'll bring mine via this jigger.Have read.

 

Music in the Round #92: Digibit Aria Piccolo +

 

 

 

718mitr.promo__0.jpg

Lovers of high-resolution multichannel sound still don't have it easy. While the two-channel market is replete with snazzy, efficient music servers in stylish boxes, the only multichannel equivalents are Merging Technologies' Merging+Player Multichannel-8, and a handful of stereo devices that are rumored to do multichannel, though no such claims are made in print. To be candid, the latter will play multichannel tracks via USB, Ethernet, or HDMI outputs to suitable DACs (but that's another story), but because they're aimed at the two-channel market, they tend to skimp on the CPU horsepower and RAM needed to handle higher-resolution multichannel files. Even the Merging+Player Multichannel-8 ($13,500), with its Intel i3 CPU running Roon, couldn't entirely keep up with everything in my library.

Among the many multichannel wannabes was DigiBit's elegant Aria music server, which I reviewed in March 2015. At the time, I noted that DigiBit's website made "no mention of the playback of multichannel files," though their representatives told me that all Arias could play multichannel files. Sure they could.

The datasheet for the Aria Piccolo + boldly announces "Multichannel Support via HDMI and USB outputs." This piqued my interest, not only for the overt declaration of multichannel support but also for the mention of HDMI. Given the fact that, currently, there are only three multichannel USB DACs on the consumer market, we should welcome support for HDMI so that we can play multichannel audio through an AVR or preamplifier-processor.

The Piccolo + runs a Celeron CPU and 4GB RAM and comes in three configurations, depending on the internal storage capacity: 1TB SSD,  ; 2TB SSD,  ; or 3TB HDD,  . It includes a standalone USB DVD drive for ripping CDs, with automatic ripping and tagging features. I opted for the 3TB version, as uncompressed multichannel files are about six times the size of equivalent two-channel files. On the other hand, none of the three configurations is constrained by the internal storage—the Aria can access and play files from a NAS or a directly attached USB drive.

At 17" wide by 2.4" high by 9.8" wide and 13.25 lb, the Piccolo + is somewhat smaller than the original Aria, and though it lacks its predecessor's beautifully sculpted, and no doubt expensive to machine heatsinking, its looks are equally elegant. There are no visible heatsinks—the Piccolo + clearly relies on radiating heat from its sealed and smoothly machined case. Throughout my testing and listening, it never got more than barely warm to the touch.

718mitr.picbac.jpg

The black front panel is empty but for the illuminated On/Off button. A lot more goes on around back. At left are pairs of RCA and XLR analog output jacks that are fed from the internal stereo DACs, and above them is the single HDMI connector. In the middle of the panel are AES/EBU (XLR), S/PDIF (RCA), and USB output jacks, along with a LAN (RJ45) jack and a USB in/out port for local storage devices. To the right are an IEC power inlet, the main power switch, and a connector for a possible future dedicated linear power supply.

The Piccolo + is operated via DigiBit's iAria app, which I downloaded to my iPad from the Apple Store. (There's a version for Android devices.) After I'd connected the Piccolo + to my LAN and powered it up, the app found it, then presented me with a well-designed GUI, with which all setup and playback functions can be controlled. The iAria supports automatic tagging and display of album-cover art via web access to Discogs, FreeDB, GD3, MusicBrainz, and SonataDB (classical). Albums and tracks are accessible by almost any category, and there is full playlist support. In addition, the GUI permits user editing of tags and cover art, as well as library backup.

The setup options offer a degree of user control suitable for a music server. But, consistent with DigiBit's intention of making everything as foolproof as possible, there's no real access to the Aria's operating system. For instance, I could send files from the Piccolo + via the stereo analog outputs of the built-in DAC, or via USB 2.0 if no special driver was required. (The Piccolo + is compatible with Apple AirPlay and DLNA.) But to use my exaSound e38 DAC, I had to e-mail DigiBit, who then magically downloaded and installed the driver in the Aria overnight. Now, I prefer a more hands-on approach, but I have to admit that, with DigiBit's way of doing things, there's no way the user can screw things up.

718mitr.pic2.jpg

After testing the Aria's communication and playback via the exaSound e38 with the provided sample files, I directed the Piccolo + to access my NAS, then told it to add to its library all of the more than 20TB worth of music files stored there. This was not accomplished instantaneously. While the Piccolo + was busy doing all that, I played some of the files. All two-channel formats played well, as did multichannel 24-bit/96kHz PCM and DSD64 files, but to my great disappointment, all higher resolutions played only with frequent interruptions. "Here we go again," I muttered.

But the Piccolo turned out to be much better than that. First, I canceled the comprehensive library process and instead downloaded only about 2TB of music to the Aria's HDD. Listening to those, I found that the Piccolo + played everything, including DXD and DSD256 in multichannel, without a burble or hesitation or interruption. The sound from the e38 and the rest of my Manhattan system was as clean, smooth, and satisfying as ever. From this, I concluded that the frequent interruptions I'd heard earlier were the result of playing hi-rez multichannel files while the Piccolo + was busy transferring my entire library over the network.

I then asked the Piccolo + to add another 2TB of files to its library, but without downloading them to the Piccolo's internal HD. Only after that process was completed did I try to play any of them over my LAN, and again, it was everything I'd hoped for. The logical conclusion: The Piccolo + could play every music format I had on hand, either from internal or network storage. That it couldn't play the highest-density files while simultaneously adding files to its library over a network was no big deal. As my mother said, "First, finish your homework; then you can go out and play."

718mitr.pic3.jpg

What about HDMI? I toted the Aria Piccolo + up to our place in Connecticut, intending to plug it into one of the HDMI inputs on my Marantz AV8802a preamplifier-processor, but there was another wrinkle: HDMI output is not enabled on the Piccolo + by default, but requires an e-mail request to DigiBit to activate it via the Internet.

Playing files on the Piccolo + and sending them via HDMI to the Marantz was completely successful, with two small limitations and one convenient advantage. The first limitation is a common one: HDMI output from the Aria's Intel motherboard doesn't support DSD, but converts DSD to hi-rez PCM on the fly. The second limitation is the Marantz's inability to accept any input resolution higher than 24/192. If your pre-pro can handle more, the Piccolo + will do it, as I proved by using it in my Manhattan system. The advantage: You can apply to the feed from the Piccolo + all of your AVR's audio-processing facilities, including room EQ, bass management, or whatever else it has onboard.

Given the closed structure of the Piccolo +'s GUI and its not-ready-for-gaming CPU, there's no easy way to implement bass management or equalization. For the same reason, massive library operations should not be performed while listening. Normal operations, such as adding a few albums, are not problems.

 

I'm happy to say that DigiBit's Aria Piccolo + is a well-integrated music server that's delightfully capable and easy to use. With suitable attached devices it will play uncompressed (AIFF, WAV) and lossless (ALAC, FLAC) formats up to 32/384 PCM, as well as DXD (32/352.8), DSD64, DSD128, and DSD256 files in glorious multichannel. It was a pleasure to use, and will suit the needs of almost any aficionado of music and multichannel-sound.

 

 

 

Link to comment
Share on other sites

Not to difficult to put the same track on a drive twice, once in FLAC followed by Wav.

Play both and listen Back to back for your preference.

 

For ripping I’m a fan of dbpoweramp, thanks for asking ?

  • Like 3
Link to comment
Share on other sites



Maybe we need a new thread to discuss formats.

 

I am confused. At the beginning of this thread it seemed FLAC and / or compression caused too much CPU load. Now it seems there is not enough load to stop the CPU from shutting down and when starting up causes delay that causes packet jitter that effects DACs.

3 hours ago, rmpfyf said:

Conversion to a native format effectively means removes the need to spool up intermittently... operation is temporally smoother.

@rmpfyf what is the conversion to native format you mention ?

Link to comment
Share on other sites

Guest rmpfyf
14 minutes ago, Cruncher said:

Maybe we need a new thread to discuss formats.

 

I am confused. At the beginning of this thread it seemed FLAC and / or compression caused too much CPU load. Now it seems there is not enough load to stop the CPU from shutting down and when starting up causes delay that causes packet jitter that effects DACs.

@rmpfyf what is the conversion to native format you mention ?

 

What? No one has mentioned anything about it being too much CPU load. Or CPUs shutting down and starting up - C states are called out explicitly.

 

You're smart enough, judging by your posts, not to be facetious about this.

 

In my case I go FLAC >32 bit PCM pre playback... Which is what would happen on the fly if I played back a FLAC file.

Link to comment
Share on other sites

I am not been facetious at all.

 

As far as where the topic of CPU power was mentioned.

 

11 hours ago, frednork said:

some say that flac files as they require more cpu power to extract are inferior

The way I interpreted the comment was  frednork had heard / read that CPU increase caused the drop in audio quality . I have read other threads where de-compression (higher CPU) caused a drop in audio quality.

 

You mentioned C-State. I am familiar with it only from BIOS settings which I associate with power savings so I looked up some Intel documentation here  Intel C-State which says "C1-Cn represent idle sleep states where the processor clock is inactive " and you said "Flac playback isn't enough to consistently boot a modern CPU into a C-state" ... which I assumed FLAC playback was not enough to keep the CPU at C-State C0, that is busy and not idling down. Intel openly documents the delays when coming out of C1-CN state.

 

So this stage of the thread I am wondering does music put too much load on the CPU or not enough ? or is there a third option I am missing? I don't know much about the different formats, people say they sound different and the way my mind works there should be a logical explanation.

 

When I first got into audio I was looking for a Integrated Amp and I learnt tons from @Cafad and his posts. Also I have learnt lots from others on the forum.

 

Since Cafad had only joined in the Computer Audio game recently by plugging a HDD into his Oppo I thought the appropriate level was of discussion for the thread was on the lines of 'some people think format A is better than format B, put a FLAC and Wave file onto a USB stick and see which one you like'.

 

I personally was intrigued with the comments around formats / compression / OS / jitter etc and wanted to discuss it further but I thought it would be better in a separate thread. 

 

Link to comment
Share on other sites

Guest rmpfyf

@Cruncher thank for for explaining.

 

The overall load whether FLAC or anything else is very small. It's how it's managed.

 

Intel does list C state latencies, they can also be polled from the command line in Linux.

 

During five minutes of playback there's a few hundred thousand changes of combined power and C state if the CPU is left to throttle automagically. This can be forced to some degree with aforementioned compromises.

 

In a net sense when there's less variance in latency. This is closer to the issue than, IMHO, net CPU load. I used to have data on this from experiments I'd done though it's packed away presently.

 

Broad strokes here and there's a ton to deep dive.

 

If you're Linux it's easy to test - identify your device end format, convert to it, have a go with aplay or similar. 

Link to comment
Share on other sites



  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...
To Top