Clip Zip Battery and AAC issue

I just got a new Zip few days ago and i found some problem:

  1. After full charge at night, battery remains 77% in next morning, I was turned it off after full-charge. 

  2. I decode FLAC to AAC in M4A container, Zip play pretty good when lcd screen stills light-on, but when it offs after some second, the sound turns to some kind of distort, the higher bitrate the more distort you can hear and it stop when lcd screen light-on again.

I tried both Nero AAC (vbr,cbr,abr) and iTune AAC, you can check 2nd problem with my sample:

Nero AAC Vbr ~320Kbps: (NeroAACVbr320k)Avril Lavigne - Nobody’s home.m4a

iTune AAC ~270Kbps: (ituneAAC)Avril Lavigne - Nobody’s home.m4a

Hope sansa can fix these problem asap!

That’s ok with mp3 vbr0, but in my opinion, aac has more perfect sound and wider spectrogram than mp3 even just a little bit :smiley: anyway, hope sansa can fix this :wink:

@orino wrote:

That’s ok with mp3 vbr0, but in my opinion, aac has more perfect sound and wider spectrogram than mp3 even just a little bit :smiley: anyway, hope sansa can fix this :wink:

At high bitrates, theres not much difference.

Also, wider spectrogram isn’t better.  

 

 

Also, wider spectrogram isn’t better.  

Totally agree with bitrate issue, but i don’t think “wider spectrogram isn’t better”, most people hardly distinguish between not-too-low quality audio source and high quality one (both encoded in same bitrate and format) just by hearing, so we can use spectrogram as the next solution to detect the bad one, but we still cheat it with some trick. However, good audio source almost comes with good spectogram.

Apologize for my english :slight_smile:

Orino,

I had the same playback issue with high bitrate AAC files converted from FLACs for iTunes.  These all played fine in iTunes and on my two iPods, but on the Sansa they sound good only until the screen goes dark.  Then the sound quality quickly degrades to unlistenable.  I told online customer support about this issue over a month ago, but they seemed disinterested in pursuing the issue.  I have since converted all AAC files to MP3 to get around this issue and to get the files to load from the SD card I use.  AAC (M4A) files I tried to load to my SanDisk card would never complete the refresh cycle on restarting the player.  I reported this issue on another thread some time ago.   I just updated to the latest firmware 01.01.17, but I doubt this remedies either of these AAC issues.  SanDisk’s AAC support is currently a minefield of issues. You best avoid it for now. Use MP3 format.  

The main issue I am still having is excessive refresh times for even small changes to player content if you have a card inserted with sizeable content (3000 songs).  Just adding and deleting a few podcasts can take over ten minutes to finish refresh with 3000 files on the card.  I didn’t have near this refresh delay with iTunes and an iPod for minor content changes.

To apply the new firmware I had to remove the card.  When I reinserted the card and turned the player back on tonight it took over an hour and a half for the player to finish refresh and be usable again. I had no content on the player and 29GB on the card.

I am exploring whether editing the file tags will help speed the load process. Unfortunately, SandDisk has provided little or no guidance on what specific tag issues slow up their refresh code.  This leaves the customer essentially in the dark trying to guess what changes they need to make to compensate for inadequate SanDisk code.  The tags that work so well in iTunes may trip up or slow up the SanDisk content load process.  You would think this would be a common migration path (iTunes to SanDisk player) and that this path would have been tested and perfected and not require tag tweaking, but unfortunately the more I read the forum posts, the more I hear suggestions that mention tag cleansing to resolve load delay issues.  A sad state of affairs.

GPH

@orino wrote:

 

 

Also, wider spectrogram isn’t better.  


Totally agree with bitrate issue, but i don’t think “wider spectrogram isn’t better”, most people hardly distinguish between not-too-low quality audio source and high quality one (both encoded in same bitrate and format) just by hearing, so we can use spectrogram as the next solution to detect the bad one,

You should not do that.  I can easily make a 64 kbps mp3 file with a wider spectrogram then a 320 kbps AAC file.  If you just look at the spectrum you would have to conclude that 64 kbps > 320 kbps.  Its not :slight_smile:  Hell I can make mp3s with wider spectrograms then WAV files.  Doesn’t mean MP3 is better then WAV :smiley:

The width of the spectrogram is just an encoder setting.  You can make it as wide or as narrow as you like when preprocessing the PCM.  It doens’t really say anything about the quality of the file.  So its silly to pick formats based on it  …

  1. I decode FLAC to AAC in M4A container, Zip play pretty good when lcd screen stills light-on, but when it offs after some second, the sound turns to some kind of distort, the higher bitrate the more distort you can hear and it stop when lcd screen light-on again.

mine zip too!