Thanks, oblivion. Please let me know the chapter and phrase in which they occur. I'll track them down and correct the manuscript, then update the ebook on the various sales channels.

-kyrathaba (September 09, 2013, 08:53 AM)

I thought "easy" and then failed to find them in the document on my netbook. But I'm reading the Amazon ebook (my Kindle's more portable than the netbook!) and it occurs to me that might be an older revision...

Sorry -- I may be casting unwarranted nasturtiums ;)

apparently GCHQ have a similar project (though given the UK don't seem to be able to set up any government IT systems that aren't obsolete before they get them working I am not losing any sleep).

-Carol Haynes (September 06, 2013, 11:15 AM)

That's mostly because most of the operational requirements are written by people who (a) are basically naive about what computer systems are capable of, and (b) are desperate to believe any line of BS that a salesman trots out. We'd write them ourselves, I suspect, if it weren't for the fact that real terms investment in the public sector keeps getting p*ssed up the wall by the same people responsible for (a) and (b) above.

Consider: the (UK) NHS National Programme for IT pumped several billion into a series of projects that were defined in terms of what was on the relevant wish lists at the time, not in terms of what was technically achievable. At least one of the systems procured under it went live before agreement about the dataset it was intended to manage and distribute was even agreed. It still works like it's broken and its data -- which should be the freshest, most up-to-date available -- is often inaccurate and sometimes dangerously so.

The UK paid a small fortune for systems that were not fit for purpose, in many cases never went live but somehow the suppliers got paid anyway. That's what we get for putting bloody old Etonians and Arts graduates in charge of Complicated Things. [/rant]

Still, the upside of the money wasted on NPfIT is probably that it couldn't be given to GCHQ instead. ;)

Great! Let me know how it works for you!  :Thmbsup:

-c.gingerich (August 06, 2013, 05:58 PM)

It's been okay, but I've just had something very odd happen...

It MIGHT be because the title tag of the last imported track was formatted as "artist name" + "forward slash" + "title" -- I claim no responsibility for that, it was as whatever online CDDB archive delivered for that CD when I ripped it -- but the upshot is that while the program still seems to be responsive (I've just dragged the file column wider to display the full filename and that worked fine) the Artist and Album columns for that track are displaying garbage and I can't delete that entry, I can't start a new playlist and try again, in fact none of the buttons respond to a keypress (beyond the tiny visual feedback indicating that they've been pressed). I can't even close the program.



I'll forcibly close it and see if I can pin down an exact trigger (assuming the behaviour's repeatable!) and let you know anything I discover...

[later]

Okay, I'm still getting garbage in the artist and album columns, but I'm wrong about what's causing it -- editing the tags in Opus to remove the slashes hasn't helped. All the tracks on the album exhibited something similar... However, the program's working as expected apart from that, now -- I can't replicate the bit where it went mostly unresponsive.

I'll have to drop the file into a tag editor that can show me more detail of the tag info to see if there's something corrupt I can't currently see.

[later still]

I did that, and couldn't see an obvious problem. The tags were v3.2 and looked as you'd expect.

So I rewrote them all anyway: inserted "various" into the album artist tag, cut the artist name out of each title and pasted it -- minus the <space><slash><space> -- into the artist field. Finally renamed the files themselves to <trackname><space><dash><space><trackname>.

If I were the patient sort, I'd have changed one thing at a time until it worked properly. I'm not the patient sort. Sorry. It works as expected now, anyway. Oh, except that I'm getting "various" for the artist, so presumably either you're using the content of the album artist field or the tag editor I used has it backwards. No biggie.

Strikes me that it's most likely that whatever created the tags in the first place (I have no idea but it would probably have been CDex or fre:ac/BonkEnc as it was in 2010 and that's about when I started using things other than CDex) stuffed something up and me rewriting the tags has unstuffed them. Unless it was something to do with the slashes.

[yet later still]

I think it's something to do with fre:ac. That's what I use for MP3 ripping and conversion pretty much all the time now and I've just seen similar behaviour from a track I ripped only a couple of weeks ago. Phooey -- I LIKE fre:ac.

No, it's not that consistent. The more I play, the less I can get an idea of what the problem is. :(

Any ideas about what might be going on? I should think the problems aren't worse than cosmetic -- I still haven't replicated the crash and it's only the (entirely non-controversial) filename that's being written out, after all -- but if the tags, as written by fre:ac, aren't behaving properly I should probably think about ways to identify and then clean up the problem...