I’ve never been able to properly tag my 2-CD albums to play in proper track sequence with my Sansa Clip. The player insists on playing CD1-01, CD2-01, CD1-02, CD2-02, etc.
I’ve tried the conventional wisdom of using ID3v2.3 ISO-8859-1 (written via the MP3tag software app), and confirmed the tag format with a hex editor. Still no joy.
Typical format is:
TPOS = XX
TRCK = XX
All other tags properly written and recognized by the Clip. I’ve also tried unicode tagging (both ID3V2.3 and ID3V2.4 formats).
It’s hard to believe that Sandisk still doesn’t have its act together wrt ID3V2 tagging and play order, so someone please tell me where the problem lies.
I’ve never been able to properly tag my 2-CD albums to play in proper track sequence with my Sansa Clip. The player insists on playing CD1-01, CD2-01, CD1-02, CD2-02, etc.
I’ve tried the conventional wisdom of using ID3v2.3 ISO-8859-1 (written via the MP3tag software app), and confirmed the tag format with a hex editor. Still no joy.
Typical format is:
TPOS = XX
TRCK = XX
All other tags properly written and recognized by the Clip. I’ve also tried unicode tagging (both ID3V2.3 and ID3V2.4 formats).
It’s hard to believe that Sandisk still doesn’t have its act together wrt ID3V2 tagging and play order, so someone please tell me where the problem lies.
Currently running firmware version v1.01.35A.
I don’t think very many players at all read the discnumber tag. I rip double albums as (Disc1) and (Disc 2), but maybe if you numbered them 101, 102, 103, and 201, 202, 203, that might work.
That’s how I number the tracks right now to get them to play properly. Unfortunately, it’s tedious (if I remember to do it at all).
As for not many players supporting the disnumber tag…very respectfully (I’m sure you’re a nice guy)…that’s nonsense. Start with Apple (they definitely do) and work your way alphabetically down the list of other manufacturers that offer full ID3V2.3 support. Most, if not all of them do. Sandisk excluded.
Based on perusing the forum for the past few minutes, Sandisk had this working in earlier firmware revisions (1.01.19 has been reported to support discnumber). Reportedly, 1.01.29 broke it, and it remains broken.
Sandisk seems to have captured a good little chunk of the market. Not supporting something as ubiquitous as disc number tags does not build confidence.
That’s how I number the tracks right now to get them to play properly. Unfortunately, it’s tedious (if I remember to do it at all).
As for not many players supporting the disnumber tag…very respectfully (I’m sure you’re a nice guy)…that’s nonsense. Start with Apple (they definitely do) and work your way alphabetically down the list of other manufacturers that offer full ID3V2.3 support. Most, if not all of them do. Sandisk excluded.
Based on perusing the forum for the past few minutes, Sandisk had this working in earlier firmware revisions (1.01.19 has been reported to support discnumber). Reportedly, 1.01.29 broke it, and it remains broken.
Sandisk seems to have captured a good little chunk of the market. Not supporting something as ubiquitous as disc number tags does not build confidence.
I don’t remember where I read that few players supported the discnumber tag, but it wasn’t too long ago that I did. I wouldn’t know if the Apple ones do or not…I have one but I don’t use the Apple firmware on it.
My landfilled 1st gen iPod Shuffle read the discnumber tag. My old Zen Micro read the discnumber tag.
Ignoring something as ubiquitous as the ability to play a 2-CD album in proper track order is a sad statement about a company’s commitment to producing a product that works under normal circumstances.
Pehaps Sandisk should stick to producing flash memory and leave consumer product development to companies like Apple, Creative, Sony, Microsoft, etc.
Well, it seems to me that you can argue about the disc number issue or simply adapt to it, such as, as others do, by putting a parenthetical disc number after the album name (e.g. Chess (1) and Chess(2)).
And then you can argue about why the Apple Shuffle doesn’t include a radio.
Well, it seems to me that you can argue about the disc number issue or simply adapt to it, such as, as others do, by putting a parenthetical disc number after the album name (e.g. Chess (1) and Chess(2)).
And then you can argue about why the Apple Shuffle doesn’t include a radio.
Or voice recording. Or expandable storage. And at a higher price.
Sure, let’s all adapt to a missing feature that should be ubiquitous and was broken by Sandisk themselves.
Then, to be sure, let’s mention a few features that other players might not have at the same price point as excuses for not fixing said problem.
Brilliant argument, folks. I’m sure computer challenged Clip users across the globe are out now brushing up on their ID3 tagging skills.
Well, first off, if we’re talking the Shuffle, it’s hardly “a few features” (let alone the importance of those features) at the same price point: memory capacity, memory expandability, screen, radio, recording capability, folder navigation …
But putting that aside, my suggestion simply was to move on with matters and easily adapt (as I found I had to do on this issue years ago, adding the disc number to the album name), as people have suggested. You’ve already made you point in 3 or 4 separate threads here. I’m sure that SanDisk has heard your feature request. I’m not sure what further arguing on the point (often to the choir) accomplishes, other than venting (or getting more frustrated)–better to adapt (or move on), it seems to me.
And as to ID3 tags, they’re the standard at this point, whether we like it or not. And really, not hard at all to type in and add in or edit when ripping a CD, or otherwise to add in or edit.
Thanks for your more thoughtful post, Mike. The only reason other players came up is because someone suggested that not supporting the discnumber tag is the norm. Building a strawman argument as a reason for not fixing the issue does a disservice to all who would benefit from a fix.
The point is not to argue the merits of other features as a compromise (obviously), but to bring the issue to the attention of Sandisk. Hopefully, this (and updating 2 other pertinent threads - one with clearly outdated information) gets things back on track toward a fix.
If anyone wishes to continue arguing the merits of fixing this issue, feel free to start another thread (or continue to derail this one).
Thanks for your more thoughtful post, Mike. The only reason other players came up is because someone suggested that not supporting the discnumber tag is the norm. Building a strawman argument as a reason for not fixing the issue does a disservice to all who would benefit from a fix.
The point is not to argue the merits of other features as a compromise (obviously), but to bring the issue to the attention of Sandisk. Hopefully, this (and updating 2 other pertinent threads - one with clearly outdated information) gets things back on track toward a fix.
If anyone wishes to continue arguing the merits of fixing this issue, feel free to start another thread (or continue to derail this one).
I never claimed that as a reason for them not to address it. But given how long it took them to address gapless playback, I hope you’re not in any hurry for them to change the discnumber tag handling…hence my suggestions of the alternative numbering, which you said you already do, or adding the Rockbox firmware, which makes the whole player better.
After installing Rockbox, I discovered that booting into Sandisk firmware mode allows the Clip to respond to ID3V2.3 UTF-16 tags for proper discnumber and track playback.
I decided to force a Sandisk firmware upgrade by dragging the m300a.bin file into the root directory and rebooting. After rebuilding the database, the Clip now boots into the Sandisk firmware natively, and still responds to the UTF-16 tags properly for discnumber & track playback order.
There are some oddities in MTP mode (music dir appears empty), but MSC mode is fine. I’d like to know what the mechanism is that allows the Clip to read UTF-16 encoded tags properly wrt play order. Rockbox must be doing something in the background.
Rockbox shouldn’t be doing anything , in the background or otherwise. Reinstalling the stock Sandisk firmware disables Rockbox. You’ll have to reinstall it if you want to use it again.
It sounds as if reapplying the OF has brought the disc no. capability back?
On a more basic question: what does the disc no. tag do in operation/how does it actually work within the context of the operation of the Clip? I understand the goal (getting the player to play the first disc’s tunes before those of the second), but for the life of me, I can’t see how this all would operate.
edit:
I think I get it now: you throw all the discs’ tunes in a single folder and then the player plays them in order, organized by disc and track no.? My conceptual problem, I think, stems from the fact that I typically put the tunes of each disc in a multi-disc set into their own folder, with the folder name including the disc no. And then, using Rockbox for my jukebox player and setting it for folder advance, the Rockboxed player plays the first folder/disc first followed by the second, etc.
There are some oddities in MTP mode (music dir appears empty), but MSC mode is fine.
I’m not sure I follow here, but is this the basic issue that a computer only sees on the Clip the files that were transferred to the Clip in the mode that the computer then is connected under?
Rockbox shouldn’t be doing anything , in the background or otherwise. Reinstalling the stock Sandisk firmware disables Rockbox. You’ll have to reinstall it if you want to use it again.
That’s what I would have assumed, too. It doesn’t explain the fact thathe stock firmware is properly dealing with the UTF-16 discnumber tag.
