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.
@singlemalt wrote:
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.
@singlemalt wrote:
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.
If the .19 firmware supports it, you could downgrade, if you wanted…here is a link to all the Clip firmwares. (although I don’t see a .19 in the list) http://www.anythingbutipod.com/forum/showpost.php?p=187270&postcount=1
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.
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.
@singlemalt wrote:
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.
Rather than continue to argue about it, you could also install Rockbox on your Clip…I do believe it supports your discnumber tag.
@singlemalt wrote:
I’m sure computer challenged Clip users across the globe are out now brushing up on their ID3 tagging skills.
They are if they end up here and want things to work. If not, then they go out and spend twice the money on an ubiquitous iPod.
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).
@singlemalt wrote:
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.
I decided to adopt Rockbox. Thanks for the push. It’s unfortunate that Sandisk can’t get their act together.
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.
@gwk1967 wrote:
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.
@miikerman wrote:
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.
As far as how the Clip determines order, I’m pretty sure the player builds a database by parsing ID3 tags for all files present. When you navigate through music in the Clip, you’re actually navigating the database that was built using the files’ ID3 tags. Play order is probably determined based on how the database chooses to order the files according to discnumber and track tags.
That would explain why the Clip needs to build/update after you unplug it from USB after having loaded new files onto it.
The stock firmware has reportedly never been able to parse the UTF-16 discnumber tag properly to determine proper playback order. It’s never worked for me with any firmware revision (including the latest). I’m at a complete loss to explain the behaviour.
One last data point. Before I manually loaded the stock firmware back onto the Clip, the stock firmware that Rockbox allows you to boot under (press left button while turning on) was also parsing the discnumber track properly. That was the incentive to manually load back the old firmware (as the default boot) with the Rockbox load still present.
I wonder if the Rockbox bootloader is still in play here.
@miikerman wrote:
Perhaps it was as simple as a firmware code defect issue (it happens), that got fixed when you reapplied the firmware.
Two reasons I don’t think that’s the case:
-
I reverted to a full stock setup after reformatting the player. Problem back.
-
The Clip has never supported UTF-16 discnumber tags. Only ISO. At least in my experience and according to the threads I’ve read.
Went through the whole Rockbox setup + stock firmware overwrite again and UTF-16 discnumber tag back to being supported.
There’s something more to this.
Hey, as long as it works…why question it?
Exactly. I’ve already invested enough time on this. It’s working for me, and I’ve tried to get the ball rolling on getting this thing addressed at large. Moving on…
