Sandisk Clip Sport audiobook problem

3300- 600 MB per book? In how many files? What format and bitrate? For spoken word podcasts, I convert them to 32kbps mp3 mono right after I download them to save space. Using a low bitrate also increases battery life. If a speaker is moving while he is talking, listening to it in stereo can give a dizzying feeling. The Clip Sport has a less capable processor than the Clip+, although its power usage is only around 45% of that of the Clip+. The Clip Sport might have trouble with very large files in certain formats.

@jk98 wrote:

3300- 600 MB per book? In how many files? What format and bitrate? For spoken word podcasts, I convert them to 32kbps mp3 mono right after I download them to save space. Using a low bitrate also increases battery life. If a speaker is moving while he is talking, listening to it in stereo can give a dizzying feeling. The Clip Sport has a less capable processor than the Clip+, although its power usage is only around 45% of that of the Clip+. The Clip Sport might have trouble with very large files in certain formats.

Audible Enhanced mode comes in an Audible specific format as a single file that works out to about  28MB per hour. Depending on the narration speed, most books will average around 10 - 15 hours, 7 - 8 hours is on the low end for most novels and it’s not unusual to find audiobooks in the 15 - 24 hours range. The longest I’ve seen is Atlas Shrugged at 62 hours. As such, a 4GB player is more than adequate.

“Audible Enhanced mode comes in an Audible specific format as a single file that works out to about  28MB per hour. Depending on the narration speed, most books will average around 10 - 15 hours, 7 - 8 hours is on the low end for most novels and it’s not unusual to find audiobooks in the 15 - 24 hours range. The longest I’ve seen is Atlas Shrugged at 62 hours. As such, a 4GB player is more than adequate.”

The problem is that the Clip Sport has a rather limited amount of ram, so it is likely to choke on larger files, especially if they are in a format that is more complicated to decode than mp3. I guess Sandisk should have probably said ouright that the player can’t play very large files. Having said that though, the Clip Sport only uses around 45% of the power that the Clip+ and Clip Zip use, so they could make a player with huge battery life that still light and small using the Clip Sport circuitry and a somewhat larger battery than the Clip Sport has. Most people don’t tend to play very huge files. They tend to play mp3 files that are typically 15 minutes or less, or podcasts that might be up to an hour or two, but that are at a low bitrate(perhaps 32kbps?).

@jk98 wrote:

The problem is that the Clip Sport has a rather limited amount of ram, so it is likely to choke on larger files, especially if they are in a format that is more complicated to decode than mp3. I guess Sandisk should have probably said ouright that the player can’t play very large files. Having said that though, the Clip Sport only uses around 45% of the power that the Clip+ and Clip Zip use, so they could make a player with huge battery life that still light and small using the Clip Sport circuitry and a somewhat larger battery than the Clip Sport has. Most people don’t tend to play very huge files. They tend to play mp3 files that are typically 15 minutes or less, or podcasts that might be up to an hour or two, but that are at a low bitrate(perhaps 32kbps?).

Thanks. This is the frist description beyond merely stating “hardware limitations” that actually explains the issue with audiobooks and clearly indicates that a firmware update is unlikely to ever address the problem. It also suggests that the direction Sandisk seems to be going is unlikely to ever consider designing a player that will meet my set of features for the ideal audiobook device.

Rather than blaming Sandisk, you should blame Audible. I don’t know why they need to use such huge files for audiobooks, and why they can’t break up an Audiobook into a number of files. i don’t use audiobooks, but do download podcasts. Many that I download are already at 32kbps, but those that are at a higher bitrate I convert down to 32kbps before putting them on my player. There is no need for high bitrates for spoken word files. For music a bitrate of 256kbps or 320 kbps is recommended. For voice files though, 32kbps mono is fine.

Actually, those “recommended” (from where?) bitrates for music are relatively high and my hunch is that the average person wouldn’t see (hear) much, if any, difference with music ripped at a much lower rate.  Years ago, I tested it out and couldn’t see (hear) a difference starting at a bit less than 192 kbps, for music.  I also recommend ripping using VBR (variable bit rate) with a higher end at the top–it just makes sense to me, for the software to use more data space where it might be needed, and less space where it is not.

Space isn’t really a problem though, except for the internal memory on the Clip Sport, as when using 256kbps or higher bitrate one probably won’t get near the 2,000 file limit. I bought Some Sandisk 32GB class 4 micro SDHC cards recently for around $13 each. As for using variable bitrate mp3 files, I haven’t tested it, however I have a feeling that they may consume more battery power than constant bitrate files around the same sound quality. I also haven’t tested the claim that 192kbps average variable bitrate mp3 files sound as good as 256kbps constant bitrate ones. When I did tests years ago, I had trouble distinguishing between 256kbps mp3 files and 320 kbps ones, so I chose 256kbps. If I was ripping CDs now though, I would use 320kbps since storage space is very cheap now. Even now,not all devices support variable bitrate playback. Years ago when I ripped many CDs I decided to avoid variable bitrate since not all devices support variable bitrate files, and many that did then had plenty of glitches in playing them. I still wonder about battery life differences between playback of constant bitrate and variable bitrate files.

As for hearing differences between files, see how well you do on this test.

http://www.npr.org/sections/therecord/2015/06/09/412271433/audio-quality-quiz-results-you-did-slightly-better-than-guessing-randomly

Yep, took that test years ago and I “flunked” it royally.  Convincing me that a lower (but still good) bitrate was just fine, for me. 

I got 4 out of 6 right, however that was in a quiet room, at relatively high volume, and not really listening to the music, but concentrating just on the high frequencies for any clues of compression. On a portable player, at low volumes, and with portable headphones, especially in a noisy environment using open earphones, I would likely do very poorly on the test. 

I still always wonder, though, how much our brains hear in an overall picture/impression/subconsciously.

@jk98 wrote:

Rather than blaming Sandisk, you should blame Audible. I don’t know why they need to use such huge files for audiobooks, and why they can’t break up an Audiobook into a number of files. i don’t use audiobooks, but do download podcasts. Many that I download are already at 32kbps, but those that are at a higher bitrate I convert down to 32kbps before putting them on my player. There is no need for high bitrates for spoken word files. For music a bitrate of 256kbps or 320 kbps is recommended. For voice files though, 32kbps mono is fine.

I’m not defendng Audible, but want to point out a few aspects where audiobooks are likely to differ from podcasts. Audiobooks do frequently have music at either the beginning and end or sometimes as chapter separaters or for chage of perspective such as point of view. There is also the category of “performance” audiobook where sound effects (gunshots, doors slamming, explosions, etc.) are liberally added. More importantly, for those not familair with audiobooks, they are more than merely spoken words. Narrators will vary pitch, tone, pace with a unique “voice” for each character in the story. Other sounds like screaming, groaning, whistling are also rendered. Really good narrators (this is a definite skill) can even inflect their voice to indicate whether the person is thinking or speaking when “he said” is not inserted. I have no idea how all this would be impacted by reduction to 32 kbps mono. 

As far as multiple files goes, this was standard in the early years when downloads of even 10’s of MB could take hours (I go back to the days of 1200 baud being fast). I much prefer a single file.

The easiest way I always got around file sequence problems was to merge the entire book into one file. Problem solved, I use Free MP3 Joiner and tag all my books in properties as “BOOKS”. I Also normall merge 2 books together so when one ends it starts the next without manipulating the player. This is better when on the bike, hiking, etc. In a novel series I’ll merge books 1&2, then 2&3, etc. switching to the next in line when I get a chance at the completion of the other. This single file also make fast forwarding or rewind very easy, no switching between files when it’s all one. When tagging your books in properties, the only tag I leave is the title, album and duration, wipe everything else to make sure there is nothing extraneous to force it into a different folder. I have a lot more advice for these Sansa Players. Sansa, get rid of the Sport and revive the Zip.

@skeetpick wrote:

I have a lot more advice for these Sansa Players. Sansa, get rid of the Sport and revive the Zip.

I don’t necessarily disagree with you–I’m still waiting for the Uber Clip–but unfortunately, the manufacturer of the chip used in the original Clip thru Zip line killed the chip off, leading to the more, um, limited chip used in the Sport and Jam.   ;(

I don’t know why user don’t just circumvent the file problem by merging. With all my audio books, I use Freemake to convert the files down to 32kpbs (quality is just fine) to minimize file size for my player, then join/merge the files in the same pass. Now I have one small file for the entire book. This also makes fast forwarding and rewind much easier because it’s all one file, you don’t have to close a file then reopen another. Then by using properties, under the details tab,  you can tag it any way you want. What I do on the player is label a folder under audiobooks just “BOOKS” then make sure all of my audiobook files are tagged “BOOKS” in the album slot. I then blank out all the other tags except “title”, and “length”, as you really don’t need any more. Then, all of my single file audiobooks wind up uner “BOOKS” in the Audiobook main folder. This works perfectly on the clip+ and clip zip, and I’m getting ready to buy and experiment with a clip sport to see if I can work around many of the new problems created by Sandisk.

@skeetpick wrote:

I don’t know why user don’t just circumvent the file problem by merging. With all my audio books, I use Freemake to convert the files down to 32kpbs (quality is just fine) to minimize file size for my player, then join/merge the files in the same pass. Now I have one small file for the entire book. This also makes fast forwarding and rewind much easier because it’s all one file, you don’t have to close a file then reopen another. Then by using properties, under the details tab,  you can tag it any way you want. What I do on the player is label a folder under audiobooks just “BOOKS” then make sure all of my audiobook files are tagged “BOOKS” in the album slot. I then blank out all the other tags except “title”, and “length”, as you really don’t need any more. Then, all of my single file audiobooks wind up uner “BOOKS” in the Audiobook main folder. This works perfectly on the clip+ and clip zip, and I’m getting ready to buy and experiment with a clip sport to see if I can work around many of the new problems created by Sandisk.

Good ideas and solutions, all.   :slight_smile:

The only question I have is whether some books might get very big (even after the conversion), potentially causing some erratic player behavior.

I think I have written your exact response to various forums many times. It seems such a simple solution to me, and obviously to you. Kudos!

One large file does work on the Clip+ and Zip but it’s not so good on the Sport and Jam. It becomes almost impossible to fast forward on these players on large files. I actually do the opposite as if I have an Audio book as one file I use a freeware programme to slit it into parts as I find it easier to navigate etc and these slpit files seem to behave themselves on my Sport as I have no problems with the order getting confused. I never use any tags as they just seem to make things more complicated.

So how does the Clip Sport sort the files, I have a book with 196 mp3’s and nothing I do fixes the ordering problem.

I have tried everything : 

-edited the mp3 tags of tracknumber 001-196. 

-edited the mp3 tags of title 001-196.

-edited all filenames 001.mp3 to 196.mp3, even that doesn’t work.

-I used software to change the dates ascending

-I copied all files to a new folder (where windows obviously sorts them perfectly) and copied them back.

Surely on of these should have worked, how is this acceptable?

I am left with the conclusion that NO ordering at all is going on.

Is there maybe old firmware that does work?

One large file is not an option for unless it syncs (like m4a in itunes).

This means this product is broken for me and I am about to return it because it CAN’T be used for audiobooks as advertised. Should have bought another ipod shuffle but it doesn’t have an sd slot.

If you have a book with 196 files that you want played in order.  Here is one idea.

    This idea will work if all 196 files are in one subfolder under Music.

    The filenames must start with the 3-digit number (as you described).

Put this this 2-line command into a text file and save as “mybook.bat”  (must be a text file, not rtf, not doc).

     @echo off
    dir /o:n /s /b *.mp3 *.wma *.wav> My196Book.m3u

Save the bat file in the same subfolder as your 196 book files.

Then use Win File Explorer and double click on the file “mybook.bat”.  The m3u playlist will be created (very fast).

Use Music mode to play this playlist.  

The files should play in your desired order (based on 3-digit prefixes in the filenames).

     (Make sure the player Shuffle is Off.)

Did Jolynn get the answer to fix the problem? I’ve been having the same trouble and much of what is discussed is greek to me. I just want the gizmo to work the way it did for the first three years’ of use!