Skip to main content

Notice

If you are using a Hotmail or Outlook email address, please change it now, as Microsoft is rejecting all email from our service outright.
Topic: Considering a switch to FLAC for mobile listening (Read 2769 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Considering a switch to FLAC for mobile listening

I have a very large collection of FLAC files (~30,000) that I host on a NAS and stream to many clients (ex. Squeezebox, Plex, JRiver Media Center) at home. Currently, I do bulk transcodes to AAC at highest quality to use on my phone. I'm considering a new phone, likely a Samsung S10+, and new 512GB SD card meaning that I could store all the FLAC files on the phone. The Canadian spec S10+ uses the Qualcomm Snapdragon 855 system on a chip.

I would appreciate opinions on the following:
1) Will FLAC consume considerably more battery than high bitrate AAC when using wired headphones? Based on the research I've done to date, it sounds like FLAC will use similar to less battery than AAC. Does that sound correct? I'm unsure if the S10+, or any phones, decode FLAC in hardware or via software
2) I expect FLAC files to transcode when connected to Bluetooth headphones. Should I expect that transcoding to exact a higher battery life penalty from FLAC source files than it would from AAC source files? My Sennheiser headphones support APT-X. My Jabra's support AAC wireless. My Samsung earbuds support Samsung's propriety flexible codec

Re: Considering a switch to FLAC for mobile listening

Reply #1
If this was 2004 maybe there would have been a difference, IMO and especially for the S10, ZERO impact. You can try a few albums to see..
wavpack 4.8 -b3hx4cl

Re: Considering a switch to FLAC for mobile listening

Reply #2
imho, here question in redundancy use of lossless on mobile devises.

Re: Considering a switch to FLAC for mobile listening

Reply #3
2) there shouldn't be any difference for the encoding part because transcoding always happens, even if your songs are in one of supported formats
1) decoding of both of these should be cheap enough to make the difference too small to be relevant
so, overall, this probably won't save you any battery that's possible to measure - the difference, if any, is gonna be impractical to find given practical (in)accuracy of battery life measurement
some ANC'd headphones + AutoEq-based impulse + Meier Crossfeed (30%)

Re: Considering a switch to FLAC for mobile listening

Reply #4
Sorry to revive this post, but I would like know with @doubrown and his venture. What happened with this experience? Whether he did benchmarks or experiments between FLAC and other lossy codec. Because I just got a new phone, a Motorola One Macro. It's not the best phone. It's an intermediate phone with crap cameras, but in compensation, has a huge battery time and it is also really fast. The issue here is "two collections". I can't stand anymore mirroring everything from FLAC to MP3-V0. I'd rather just put all the FLACs in a 256GB Samsung external card. @doubrown can you light up a bit on what your experience was after a year? No biased feelings please. "Hammer" your phone if you have to, if it let you down.

Re: Considering a switch to FLAC for mobile listening

Reply #5
If this was 2004 maybe there would have been a difference, IMO and especially for the S10, ZERO impact. You can try a few albums to see..

I use WavPack -hh -x6 on a Galaxy S8+ and don't see any real hit to performance or battery life, and that's despite the fact that Android's built-in media framework has absolutely no WavPack support at all and I play them in VLC.

It's not uncommon to see a 4-5% drop in size vs. FLAC -8 with WavPack Extra High x6. Besides, I have some High Res stuff that the partial implementation of FLAC on Android can't play anyway, so I'd have to find an external player for some files anyway.

Monitoring CPU time used on my Core -i7 6560U in the laptop, WavPack Extra High x6 uses a little more than MP3. FLAC is a little less.

There is no way that running a well written lossless audio codec on a modern Android phone should be a big deal.

About the only one that might cause a problem is Monkey's Audio, which has horrendous decode performance and a terrible license that also encourages recipients to violate the GPL of other programs. Or OptimFROG, which is completely proprietary.

 

Re: Considering a switch to FLAC for mobile listening

Reply #6
I expect FLAC files to transcode when connected to Bluetooth headphones. Should I expect that transcoding to exact a higher battery life penalty from FLAC source files than it would from AAC source files? My Sennheiser headphones support APT-X. My Jabra's support AAC wireless. My Samsung earbuds support Samsung's propriety flexible codec

There's always going to be a transcode, it's just a matter of what it's transcoding from.

When you use FLAC or WavPack files as a source instead of lossy codecs that just aren't fantastic, like AAC and MP3, you will still have a lossy conversion on the fly to the Bluetooth receiver, however you avoid having a double lossy conversion which guarantees generation loss.

Even the baseline Subband Codec isn't bad assuming you're using an Android phone and not an iPhone (which implements SBC poorly), and generally is preferable to AAC over Bluetooth assuming that SBC is operating at the full 345 k/bits per second that it is capable of. The sound will be as good as with AAC, however, you avoid the more taxing AAC codec that theoretically could run your battery down, and some of the additional algorithmic delay of AAC.

Since MPEG codecs are technically obsolete warmed over 90s garbage (compared to Opus), they lean heavily on a bit reservoir, and AAC as a Bluetooth profile (at least from what I've read) disables the reservoir to keep lag and errors from packet drops down, the big advantage that it may have had over SBC is negated.

I'm personally considering investing in some LDAC compatible headphones. I love my Sony MDR-7506s, but on the go it can be a bit much. As for earbuds..... *Londo Mollari (B5) voice* NEVER!

 
SimplePortal 1.0.0 RC1 © 2008-2020