Sansa Clip and Audio Books (3 Problems)

On the strength of the review on anythingbutipod.com (Clip Review), I recently purchased 4 Sansa Clips. Imagine my chagrin when I discovered Sansa’s off-pitch bug (great sound quality indeed!). So I decided to return 3 of them to the store and keep one for audio books. But it didn’t take long before I stumbled upon further Sansa Clip bugs.

First, about my audio books. They are all basic, DRM-free, MP3. I do not use NetLibrary, OverDrive, Audible, and so on – on one hand, their audio quality is, AFAIC, rather poor; OTOH, I like to be able to play my books whenever I choose on whichever player I choose. So, the only difference between my audio books and my music files is that the former are more compressed (typically 64k or 128k) than the latter.

I came across three issues while playing my audio books on the Sansa Clip.

(1) THE BUTTONS.

The Left/Previous and Right/Next buttons behave differently for MP3 files placed in the Audiobooks folder. For files in the Music folder:

press = skip to previous/next track
press-and-hold = rewind/fast forward

But, for files in the Audiobooks folder

press = (a) on play - no action, (b) on pause - skip to previous/next track
press-and-hold = (a) on play - rewind/fast forward, (b) on pause - skip to previous/next track

I suppose that, in the classic phrase, this is “a feature, not a bug”, but it’s not explained in the manual; I find it counter-intuitive and quite annoying.

(2) THE BEEP.

On some audio books, the Clip generates a beep, something like a loud digital hiccup, right at the end of one track and before loading the next track. The beep is present in all files in the audio book, but it sounds slightly different in different files. It happens only with some, not all audio books, and if these have anything in common which they don’t share with the others, I can’t tell what it is, except perhaps that they are ripped from CD.

I recorded one of the beeps and I slowed it down in Audacity by 400%. The freq spectrum shows a very regular toothcomb-like pattern, with peaks spaced at 348 or 349Hz, the average amplitude decreasing from -14 to -70 dB. What this means is beyond me.

I tried the same file on other, non-Sansa players; none generated this beep. I checked the MP3 file with EncSpot and mp3val, they found no problem. I decoded the file to WAV with Audacity, no problem, no beep. I used MP3 Repair Tool to remove all tags; didn’t seem to make a difference. I used MP3 Trimmer to remove the last frames of the file, and the results were curious. When I removed the last 3 frames, the beep was much shorter and lower. Remove the last 4 frames, and the beep is almost inaudible. Remove the last 5 frames, and the beep is back in all its glory. It would seem then that the Clip’s problem is not related to a specific frame, but to the number of frames in the file.

(3) THE TRACK NUMBERS.

I copied an audio book to the Sansa Clip. It consisted of 142 files (tracks), neatly, fully, and correctly tagged with ID3v2.3, ie, “Book1 [001]”, “Book1 [002]”, … , “Book1 [142]”. The tag contained track numbers (1/142, 2/142, …, 142/142); the disc frame for all tags was 1/1.

And the Clip began to play them in the following order:

Book [010], Book [020], …, Book [140], Book [001], Book [011], Book [021],… and so on.

Strange days, indeed. But another book, tagged in precisely the same manner, played in the correct order. However, it comprised only 98 files. So I used a tag editor to delete all data in the TRCK frames of the ID3 tags of the first book, and, sure enough, this time the Clip played it in the correct order.

So it seems pretty clear that the Clip becomes dazed and confused when it comes across 3 digits in the TRCK frame. There may be historical reasons for it – the Red Book (CDDA) standard allowed for a max of 99 tracks/disc; hence, unless changed afterwards, tracks ripped from CD could not have track numbers higher than 99. But that was then, and this is the 21st century. If Sansa Clip uses ID3 tags to order the tracks, it should follow the ID3 standard, not the Red Book; and there is no such limitation in ID3 (see ID3.org).

  1. The buttons took a little getting used to, but I’ve managed (sometimes grudgingly).  I still get mad every now and then when I intend to forward through a few minutes of a track and end up 20 tracks ahead. At least I’m doing it less frequently now than I used to.

  2. I think I’ve only had one audiobook exhibit a slight beep at the end of tracks.  I attributed it to the MP3 files, not the Clip, and never investigated further.  I’ve ripped audiobooks from CD with WMP11, gotten mp3 files from my neighbor’s collection, librivox.org, and Overdrive.  I don’t recall which book was the problem.

  3. I know I’ve listened to several audiobooks with more than 100 tracks without issues.  The source for my high-track-count books had shoddy ID3 tags (neighbor’s collection) so I used MP3tag to assign the track numbers before attempting to play them on the Clip. 

Are you using the current firmware? 

Thanks for your reply.

(1) I find this feature so asinine that, AFAIC, it nullifies the utility of an Audiobooks folder.

(2) I think I may have narrowed down a bit the cause of the beep. I ripped a track from an audio book on CD twice with iTunes, first in mono, second in stereo. The stereo version – no problem. The mono version – beep. So the problem seems to be caused by some interaction between Sansa’s MP3 engine and whatever iTunes does when it mixes stereo down to mono. However, none of the other MP3 players I tried (GoGear, iPod, and several obscure brands) has this problem; and, now that I think about it, I seem to recall that the same thing used to occur occasionally on my old (and now sadly defunct) Sansa m230.

(3) I’m afraid I made a mess of explaining this. Let me try again. The problem occurs only if two conditions are met – there are >99 files, hence >2 digits in the TRCK frame of the ID3 tag, AND the disc number (ie, the TPOS frame of the ID3 tag) is not blank. If the track number is blank, or if the disc number is blank, the play order is correct. Hence my surmise that the problem stems from a Red Book-based assumption that there cannot be more than 99 tracks per disc.

I’ve found the easiest way to to deal with the problem(s) you mention here is to only load I audio book at a time.  When you finish it, delete it and then load the next. I’m aware there are ways to renumber and/or merge files/chapters to work around this issue, but I find the one book at a time scheme to be the quickest and most simple.  Perfect, no, but failsafe. 

The trick for audiobooks and the previous next buttons is to ensure the Chapter Mode is set to ON. When playing an audiobook file, select the ‘down’ button (or what ever it’s called) and then set CH Mode to ON. Then pressing the Next/Previous button should cycle to the next or previous track. You can hold down either button to fast forward or fast reverse through the current audio file.

Using iTunes ripping books on CD to MP3 format in stereo and the bit rate set to 64 I do not get any beeps in any of the 30 or so books I’ve ripped. The only time I’ve heard beeps in audio was from a Libravox audiobook. The beep sounded like the one used to advance a slide projector/film strip projector from my early school years.

With track numbers I have more than a few ripped audiobooks that run more than 100 tracks, some run 200 or more. The key with audiobooks is to ensure you edit the tags for the audio file as iTunes and other rippers may not populate them correctly. Using a tagger like MP3Tag helps to change large amounts of files at the same time. Using MP3Tag I usually do a mass renaming of the track number with the Tools/Autonumbering Wizard option after I’ve ripped all the audiobook CD’s. The autonumbering wizard has the option to put leading 0 before the number. It also helps to ensure the Disc Number field is populated correctly (for some reason) if using an audiobook that spans multiple CD’s. For example I use 1/10, 2/10, 3/10 and so on for the Discnumber field in MP3Tag. I also make sure the Genre is set to “Audiobook” for all audiobook files. It also helps to ensure there are unique Title entries for each file, you can use the Convert option in MP3Tag to copy the track numbers to the title. Also ensure the same Artist name is used for all audiobook tracks as well.

The only major problem I’ve run into with the Clip+ is when I have 30 or more audiobooks or more than 5,000 individual files saved to a microSD card (in my case a 16 GB Sandisk card). The Clip will not recognize additional files or folders on the card. This is due to the 8,000 song limit the Clip has, which appears to also be influenced by the amount of file tag data one uses. I went to using Rockbox (which then presented a similar issue related to the database used to sort the media files and large amounts of files) to view and play, via the Files option, all of the content on my microSD card.

Malix,

First of all, wow, great investigative work.  Really impressive.

You mentioned ripping using iTunes.  Why not “Join CD Tracks” first, so you have one audiobook file per CD?  It’s a menu item under “Advanced”, where you select the tracks first, Join CD Tracks, then Create MP3 Version.  With the Clip’s resume function and button behavior that you loath, there’s no advantage to having MP3 files match the CD tracks.  This is what I do, no tagging work required.  (I recall a while back in some Zune forum where they came to the conclusion that we should use iTunes(!) to rip audiobooks, just for this Join tracks feature, to avoid the crappy track tag that confuses MP3 players into bad play order.)

As far as your button preference, I think most audiobook users are very grateful for this intentional feature that Sandisk added.  I can’t count how many times I fast-forwarded or rewound for a long time, and found my finger pressure yielding slightly below the threshold FF pressure, then slightly back above that threshold pressure, which got me incorrectly to the next audiobook part.  It’s a common occurrence among audiobook listeners.  Less common, but also possible, is accidentally hitting the FF or REW button.  With the common length of audiobook files of about an hour or more, it’s easy to curse the old style of push=skip FF/REW button behavior.  (With tiny audiobook files like one gets when ripping each CD track into an audiobook file, it’s not much of a problem getting back to where you were listening if you accidentally FF to the next file.)

Great information thanks to all.  The chapter mode tip was crucial - I was about to call support, and we all know how that was likely to go.  I should not assume though.

On the long vs short tracks:

I like shorter tracks so that I can quickly skip through a bunch rather than having to hold the button down.  To some degree, this is because on my old Philips Aria player, it would get lost sometimes.  I also do books for my wife’s Android phone.

I use an open source program called mp3splt

http://sourceforge.net/projects/mp3splt/  - it has a gui version as well as a command line version.

I put all the original tracks into mp3splt and break them into 5 minute segments.  It autonumbers the filenames by appending digits with leading zeroes to the name.  I then use mp3tag to copy the filenames to the title tag.

I do use mp3tag to (re)number all the tracks from 1 to n, and it has a check box to auto add leading zeroes as needed.  I normally set the album tag to be the name of the book, without numbering disks, so all tracks have the same album.  Hopefully that will not be a problem, but it is easy enough to leave it blank too.