[Logo] Jaikoz and SongKong Forums
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: mjc  XML
Profile for mjc -> Messages posted by mjc [14]
Author Message
Hm, my apologies, I suppose I didn't actually submit it, and here's why...

I've only been able to reproduce it by fiddling with itunes, foobar2000, and jaikoz' handling of id3v2.[34], but with default settings everything works OK. I'm not sure the issue that duplicates the last character is Jaikoz's per se, but it's definitely a character encoding issue - switching between id3v23 utf8/16 with and without byte order markers in the three apps triggers it at some point.

It only affects the user defined tracks (TXXX) as far as I've seen.

here's the output of http://id3lib.sf.net/'s id3v2 utility for an affected file:

MB ID's are UUIDs and have a fixed length.

Due to some (previously reported) weird issues I have had in the past that are no longer occurring on new files, many of my files have the last character repeated in one or more custom fields, leading to sometimes up to 45 characters in the MB IDs. When I tell Jaikoz to try and fix these albums, it won't do much because it thinks there's already an MB ID.

I propose that it would make sense to validate the field prior to using it , and try stripping characters (first leading, then trailing) to see if that produces a valid MBID in the case that it is greater than 33 without dashes or 36 with.

This perl regex would do both:

The i modifier is case insensitivity just in case some other tool used uppercase, and we wouldn't want to fail to validate that. Adding A-F to each character class would have the same effect but look less clean.

When using this to fix the aftermath of the bug I had encountered, looking up the mbid returns a valid result, and I would then need to update data from that existing mbid in order to fix the other fields (eg. release type "Albummmmmm", mb artist id and unique id.)

I wrote a perl script to do this for my library but it would be nice if the replacement functionality had something similar or at least find/replace had regexp support and allowed you to specify your own column name.
you might be able to symlink libc and see if that works, but it's not a mass-distributable option.

EDIT: nevermind, ubuntu has a package for it.

There is a way to trigger synaptic though, rhythmbox does it for the mp3 codecs. perhaps something similar can be done...
Here is an app (with source) that copies replaygain values to itunNORM values: http://uclc.info/ipod/

ReplayGain algorithm is here, from LAME: http://lame.cvs.sourceforge.net/*checkout*/lame/lame/libmp3lame/gain_analysis.c

Looks like an extremely straightforward port... I may have time to make a class for both in a week or two, after finals.

edit: forgot first link...
if you drag the same item to the list twice (for example when you have two references to the same file in iTunes) and run delete duplicates, it deletes the file.

Additionally it would be nice if delete put things in the trash/recycle bin instead of blowing away four albums :/
I'm trying to track down what I am pretty certain is an off-by-one.

I've managed to reproduce incorrect artist and/or album artist tags and watched jaikoz submit the incorrect tags to musicbrainz - they always are the same song title and album title as the correct match, but the artist is the same as the previous "compilation" album's artist until there is a new non-compilation artist.

Example I can think of at the moment

Offending artist name : The Immortals
found on compilation disc: Mortal Kombat: The Album
Song: Techno Syndrome (Mortal Kombat)

following this song, it marked every single Drowning Pool album I have (immediate next artist) as album artist, artist: The Immortals

Additionally, it marked all of those albums as compilations.

I had previously looked up my drowning pool albums with jaikoz and they came up fine. jaikoz submitted them all incorrectly, if you look at the edits on my musicbrainz account.

this is a link to this specific edit but it does not show you that it submitted it with a different artist ID: http://musicbrainz.org/show/edit/?editid=9754417

This album was definitely correct when I loaded only the drowning pool albums in my collection and checked them prior to this date.

If this doesn't prove to be immediately useful in tracking down the bug I would happily try to reproduce it prior to 2.6.0, but prior to that I had never had any of my music end up making any autoedits whatsoever, with either jaikoz or picard - check the edit history on my account.

paultaylor wrote:

That would be nice, but how do we differentiate between user corrected and user has messed it up. I am going to add an option to Preferences/Music/AutoFormat to strip the (disc 1), (disc 2) syntax because alot of people (inclusding me) don't like it but I'm not sure I can provide a magic bullet for all circumstances.

Of Course you can change the settings in Preferences/Musicbrainz/AutoFomat so that fields are not overwritten. 

Hmm; maybe provide a 'force fresh lookup from musicbrainz' option?

paultaylor wrote:

mjc wrote:

Check for existence of key before selecting it, exceptions are more expensive than a select before insert.

I already do, I mot sure why this is occuring but think must be a threading issue, please send me your logs.

will do shortly, reproducing it.

paultaylor wrote:

mjc wrote:

Provide a method, platform supporting, to enable the -d64 switch (x86-64 support), on at least OSX. many speedups!

On Todo list, wil come on OSX when move to Quaqua 5 interface (currently using Quaqua 4)

seems to work ok when I just use -d64 on the command line. am I missing something?

paultaylor wrote:

mjc wrote:

Remember manual corrections made after correcting from musicbrainz 

Various (buit not all) Musicbrainz lookups are cached, what exactly do you mean here ? 

OK, say the data I get back from MusicBrainz isn't quite what I wanted - eg, they give me a lot of (disc 1), (disc 2), etc. if I make that change after having done a MB lookup, and then later redo the lookup, it pulls down MB's data again. It would be nice if it recognized that as 'user corrected'.

I don't want the (disc 1),(disc 2), etc because they have the ID3 tags correct and I don't like to have a cluttered album list.
29/09/2008 06.30.43:com.jthink.jaikoz.data.id3.DateTime:getInstanceOf:WARNING: Unable to parse datetime field:1998-01-01:java.lang.NumberFormatException: multiple points
29/09/2008 06.27.30:com.jthink.jaikoz.JaikozThreadGroup:uncaughtException:SEVERE: Uncaught throwable with no error message on thread:Thread-195 caught by JaikozThreadGroup
29/09/2008 06.27.30:com.jthink.jaikoz.JaikozThreadGroup:uncaughtException:SEVERE: RuntimeException occurred in application
at java.util.TreeMap.key(TreeMap.java:433)
at java.util.TreeMap.lastKey(TreeMap.java:297)
at com.jthink.jaikoz.manipulate.ClusterAlbumsAnalyser.doGroupAnalysis(ClusterAlbumsAnalyser.java:382)
at com.jthink.jaikoz.manipulate.ClusterAlbumsAnalyser.analyseData(ClusterAlbumsAnalyser.java:117)
at com.jthink.jaikoz.manipulate.ClusterAlbumsAnalyser.run(ClusterAlbumsAnalyser.java:86)
at java.lang.Thread.run(Thread.java:613)
  • Provide option to remove itunes duplicates
  • Heuristic locating of 'dead' itunes tracks
  • Renaming of tracks that itunes has named incorrectly (extension jpeg, or no extension at all, but it's mp3)
  • Optionally use album art located in supplied folder
  • Verify existence of songs in iTunes Music Store (useful to know if the album will be usable by iTunes' Genius feature)
  • mipcore/genpuid built with x86-64 support (at least on osx; more registers should make this a lot faster)
  • Code:
     Caused by: ERROR 23505: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL080715233835090' defined on 'RELEASE'.
     Caused by: ERROR 23505: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL080715233835140' defined on 'ARTIST'.

  • Check for existence of key before selecting it, exceptions are more expensive than a select before insert.
  • Provide an interface to increase the memory limit, 300M is paltry.
  • Provide a method, platform supporting, to enable the -d64 switch (x86-64 support), on at least OSX. many speedups!
  • remember manual corrections made after correcting from musicbrainz
  • Absolutely awesome, seems to be a little faster and discogs managed to find tags for some of my missing songs.
    I have several machines here; it would be great if I could use xgrid to calculate ids.
    Profile for mjc -> Messages posted by mjc [14]
    Go to:   
    Powered by JForum 2.1.6 © JForum Team