|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
206.255.209.123
In Reply to: RE: Disagree with the FLAC Recs......... posted by Todd Krieger on September 20, 2014 at 20:56:11
I find lossless playback formats like FLAC decoded in real time to be less tolerable than even lossy playback formats like (at least 256 kbps) MP3..
Curious. Maybe more processing power was needed. When I have two Touch players decoding FLAC with different content, the quad core i7-860 CPU usage stays below 1%.
I might understand the challenge when you leave that chore to a tiny embedded processor like an Atom.
Follow Ups:
I decoded two versions of an entire album, MP3 to WAV and FLAC to WAV. In both cases, the input had been cached by the file system in RAM and the output went to a RAM disk. I measured the total elapsed time taken by the conversions. It took about 60% longer to decode the MP3 than it did to decode the FLAC. The software involved was dBpoweramp running on an Intel core i5 (2nd gen) CPU. The FLAC had been encoded using FLAC level 8 by dBpoweramp. The MP3 had been encoded using LAME, high quality setting 192 VBR, also by dBpoweramp. (FLAC level 8 uses the longest LPC predictor and hence is the most CPU intensive in decode.)
It's certainly possible that a poorly implemented player doing real time conversion could botch things up and spend more time in operating system calls, buffer juggling and unneeded data copies than the actual decoding required for the format. Hence, YMMV.
It's certainly possible that a poorly implemented player doing real time conversion could botch things up...
I think that's one reason I like the idea of having a high performance server do the decoding and streaming - located distantly from the audio system using a dedicated player connected via TCP/IP.
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: