[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: bobm  XML
Profile for bobm -> Messages posted by bobm [21]
Author Message
Everything else is working fine, but when I run Actions>File and Folder Correct>Correct SubFolder from Metadata, it produces no effect at all on subfolder path.

The prefs on File and Folder Correct>Rename Folder From Metadata, for both rename mask and compilation rename mask, is set as below. Albumartist fields have good data on all files. What could be wrong?

function ifnotempty(value,sep){
return value.length > 0 ? value + sep : '';

function ifnotempty2(value1,value2,sep){
return value1.length > 0 ? value1 + sep :value2.length > 0 ? value2 + sep:'' ;

ifnotempty(albumartist,folderseparator) + ifnotempty(album,folderseparator) + (disctotal>1 ? discno + folderseparator : '')

noted. thanks. will follow this.

as mentioned above, the workaround is to remember to inspect and manually set the compilation tag on m4a files to what I want it to be every time I open any such files, and before performing any action which is conditional on the state of this field, i.e. "Correct Filename from Metadata". Needless to say, this is rather cumbersome. Hope this curious bug gets fixed in an upcoming release.

FWIW, Jaikoz is still the best multi-format tag manager out there, especially on the OSX platform for people who prefer to avoid iTunes for whatever reason, such as lack of FLAC support !

grateful for your fine work, Paul.
Experimenting a bit further, I took an m4a file which iTunes shows as not compilation but which Jaikoz shows as compilation, and then in iTunes set the "is compilation" flag. Now, both iTunes and Jaikoz show the tag set to yes, so I assume the actual file itself is truly marked yes.

If I then edit this file back to no compilation using Jaikoz, iTunes will again show it back to its original state, without the flag set. But as above, reopening and viewing the file in Jaikoz, it once again disagrees with what iTunes shows.

Finally, FWIW, I have notice no other odd behavior of Jaikoz on these files, just the compilation tag always showing in edit view as set to yes.
Testing results:

step | action | result

1 | open Jaikoz | opens
2 | open m4a file | opens; "Is Compilation" tag shows checked in edit view
3 | uncheck tag | tag unchecked; marked as having unsaved edits in edit view
4 | save file | saved; unsaved edits mark gone; tag shows unchecked in edit view
5 | close file | file closed
6 | reopen file | opens; "Is Compilation" tag shows checked in edit view

I then did the same test, but between steps 5 and 6 I first inspected the file by adding to iTunes and using iTunes "Get Info". iTunes shows the file as NOT part of a compilation. (As mentioned above, I normally don't use iTunes at all for music, so it is not the culprit here.)

Oddly, then, it seems that Jaikoz Edit View is showing the compilation tag in my m4a files as set when in fact it is not.

The problem with this is that when I use Correct Filename from Metadata, Jaikoz then uses my compilation rename mask rather than my regular rename mask (my IP above refers), unless of course I remember each time to uncheck the compilation tag in Edit View first.

This is a problem I'd like to avoid. (Recall only the small portion of my stuff that is m4a has this problem.)

What are your thoughts, Paul?

several failed attempts over several days using safari's downloader.

The download starts but sits for as long as a day with no progress. delete and retry hasn't worked.

Got one download a few days ago which appeared complete (xx.dmg.download switched to xx.dmg), but could not get it to mount.

one factor could be that I am connecting from China, but this has not been a problem with previous releases.

any suggestions ?

EDIT 22/7: case closed. finally got a download done. installed, runs fine
good call, Paul. Turns out this is only happening on m4a files, of which I have only a very few. (Predominantly have Flac, plus a few mp3s.)

As to what's causing this, Preferences:Remote Correct:Discogs:Is Compilation is set to "never alter", so that's not it.

A little experimentation shows that I can 1) edit an m4a compilation from yes to no in Jaikoz, 2) save the file, 3) close the file, then 4) re-open, then Lo, the compilation tag is back to yes, with no other actions on my part whatsoever. Also some checking shows that this happens to all my m4a files, including I am pretty sure to m4a tracks which should not be compilations by anyone's definition.

Can't tell if the m4a files' compilation tag is being modified by my save action or my reopen action. I currently have no other tag inspector app which I could use to check between save and reopen. (Except iTunes, which I am wary of letting anywhere near my music library; iTunes doesn't do flac, and anyway, I use it only for software update, etc.)

Any ideas how to stop this from happening? thanks

I have my own custom use for the compilation tag, but Jaikoz seems to be behaving in unexplained ways, causing troubles.

Allow me to explain what I am trying to do, then explain what seems to be not working as expected.

My collection (15,000 tracks currently) is mainly played on Sonos, and my Sonos is configured to index using Album Artist rather than Artist.

I start with Musicbrainz data, but then modify quite a bit by hand. In particular, I want to use "Is Compilation" field for my own purposes, and thus I have set Prefs/Musicbrainz/Format/Is Compilation to "Never Alter".

> For albums which I want to handle as single artist, I set Is Compilation to No, and set Album Artist and Artist to be the same artist name.

> For albums which I want to handle as a compilation, I set Is Compilation to Yes, and set Album Artist to "Various Artists", and Artist to be the individual track's artist name.

In other words, I end up with Is Compilation = "yes" if and only if Album Artist = "Various Artists".

I then use Local Correct/Subfolder from Metadata for all files (Compilation or not) using:

ifnotempty(genre,folderseparator) + ifnotempty2(albumartist,artist,folderseparator) + ifnotempty(album,folderseparator) + (disctotal>1 ? discno + folderseparator : '')

Finally, I then use Local Correct/Filename from Metadata for non-Compilation files using ifnotempty(pad(trackno,2),' - ') + title , and for Compilation files using ifnotempty(pad(trackno,2),' - ') + ifnotempty(artist,' - ') + title .

Once all this is done, I then Save Changes and close Jaikoz.

Inspecting files and paths in Finder shows that my Local Correct actions all seem to have had the desired effect, and my Sonos system then indexes my files way I want it to based on this tagging scheme. So far so good.

The problem arises when I later reopen a folder previously set up this way (say, for example, to correct some errors).

On reopening, for some files the Is Compilation field comes up as "yes" for files where I had previously it set to "no". This shows up immediate I open a folder, though on only some files in an apparently random fashion, and without me doing any other actions aside from opening a folder of previously edited and saved files.

Can't figure out what could be causing this, and can't tell if the change occurs before I save or upon reopening later.

Ideas ?
apologies if this is something you already know, but folder and file names are not really very relevant in Sonos (or similar player systems for that matter.

Sonos scans all your music files and builds indices based on the tags for album, (or album artist, selectable in prefs), artist, genre, title, and so on. when you search and select stuff for playback in Sonos, you use these indices.

Sonos keeps track internally which files and folders are pointed to by the indices, but the actual folders and file names can be anything, even gibberish, as normally using Sonos you won't look at them.

If you want or need to, it is also possible in the Sonos controller to search by folder/filename instead of searching by tags, but the whole point of tags is to make more logical, powerful searching.

That said, having folders and filenames which follow a logical system will make it MUCH easier to manage your collection, using tools like Jaikoz.

There are several folder and filenaming conventions that people commonly use, and the Jaikoz defaults will be a good starting point. I think most people get their tags sorted first, then rebuild folder/filenames based on tags according to some scheme or other.

Again, using Sonos you should really care more about your tags, less about your file structure.
OK, I figured this out.

In case anyone here with similar problem is looking at this thread, this situation has to do with the differences in how MP3 tags are stored between the two standards ID3 v1 (old standard) and v2 (new).

Sonos, and presumably some other systems, want to see ID3 v2. What caused the problem was that these MP3 tracks' tags were ID3 v1, which apparently stores genre (and other tags?) internally as numbers, and Sonos is not set up to map these numbers to fixed text values in display.

To resolve, in Jaikoz I simply needed to set

preferences:save:ID3 Tag V1 to "Delete tag"
preferences:save:ID3 Tag V2 to "Always write tag"

When files were saved, things got fixed.

Note, in preferences:save:compatibility I also have all three options checked, but don't know if this was part of solving my little problem or not.

I used Jaikoz to re-tag a huge group (7000+) of tracks.

The entire group of tracks was set to a single genre tag, and to be doubly sure, I did a copy/past of the desired genre tag in the entire genre column.

I then let my Sonos system index these tracks.

Oddly, around 15% of the tracks show up in Sonos as genre "8", rather than the desired genre tag which shows in Jaikoz.

Admittedly, this could be a Sonos issue rather than a Jaikoz issue. But whether or not the problem began in Jaikoz, I would hope I can use Jaikoz to find and fix the problem.

Upon investigation I find that the "8" genre shows up in the Sonos index if and only if the track-file format is mp3. The majority of these files are FLACs, with a small number of other formats. But only the mp3s have produced this odd result.

Looking carefully at the offending files in the details pane, and in the view and view audio panes, I can't for the life of me find anywhere where this "8" data could be coming from. All tags look correct, particularly those fields which I understand are used by Sonos in building its index. All the genre tags, including the misbehaving ones, show a "1" as the number of entries for the genre field. Indeed, I can't find any "8"s anywhere when looking with Jaikoz.

A true puzzler. Suggestions, anyone?

sorry, my mistake.

didn't realize I needed to load files before import edit info.

all's well now. will continue with process as planned.

I notice that the export to excel has done the deletion of artwork for me! one less step.

A final question. is there a way to do the File and Folder Correct as a save, to an entirely new volume, rather than as a modify paths on the original volume?

Doing it this way, I won't need to worry about the old folder.jpg files in the original folders; I can just delete the entire old base path, on the old volume, after I have fixed everything else in the new volume.
sorry to pester again. another stumbling block, hope its minor.

exported edits to file as recommended (used csv rather than xls, not sure this matters)

after exporting I happened to do the upgrade to 5.2. then tried to reload the csv of all the edited tags - but it won't import.

could this be because I changed Jaikoz versions between export and import?

checked exported file in excel, data is all there. also re-saved in excel from csv to xls. Still can't import this into Jaikoz 5.2

any easy fix, or do I now need to redo my first round of corrections on 4700 files?

Thanks Paul. Amazing support!

Will try your work-around while awaiting bug-fix release.

But my other objective is to redo track file paths based on corrected tag data, but have folder.jpg files end up in the newly defined album subfolders at the same time.

Maybe my best approach for now is to correct main tags, and instead of save, copy to a whole new volume with corrected paths. Tehn do a second round of autocorrect aimed only at artwork, save this to filesystem, empty artwork column, then save again.

odd. yes, looking more closely through the edit table, I believe I was mistaken when I stated that no changes were saved.

Looking closer, it appears that:-

1) Save Changes has worked on MP3s (<5% of total) where album art was added to tags by recent Musicbrainz Autocorrect process

2) Save Changes also worked on FLACS where album art was not successfully added to tags by recent Musicbrainz Autocorrect process, but where edits were made to other fields, either by hand or Autocorrect.

3) Save Changes has not worked on FLACS where album art was successfully added to tags by recent Musicbrainz Autocorrect process.

As a further experiment, I deleted the recently added album art data from artwork field in a single FLAC file where I know that other fields in this track were also modified in recent edits, then highlighted the single file and tried Save Changes from context menu.

This Save worked, suggesting that something is choking specifically when trying to Save Changes on those FLAC files where album art has been added to artwork field.

Two more small possible clues: when doing the single file Save Changes where no data in artwork field, it was very, very slow. Spinning blue wait icon sat there for maybe sixty seconds, and only disappeared when I clicked away to a different application then click back to Jaikoz.

Also, instead of main menu Save Changes on entire table, I tried as a final experiment a single file, context menu Save Changes on another FLAC track, this time with new artwork data still there. The file did not save, and the error message came up and whole program froze for a considerable time, resumed response only after several clicks into and back from other apps. Don't know whether this is significant.

Seems Jaikoz is possibly having a hard time saving any changes in my FLACs, and having fatal trouble saving when the modified data includes artwork.

Again, Jaikoz is running on a mac, OSX 10.8.3, and the music is on a LAN based Linux Samba SMB/CIFS share, which is mounted on the mac filesystem. I tend to doubt its a file permission issue, since other apps on mac have no problem writing to this share.

Its a puzzler. Any more ideas?
report sent. thanks
First time using Jaikoz on my stuff.

My music is all on a SMB/CIFS share on LAN. Running Jaikoz on a Mac, where the share is mounted. Finder shows the share, and other apps seem to have write permission and are able to change files on share.

Jaikoz sees the files, has no problem reading all the metadata and file path data.

I bit off a 4800 track chunk of my 17,000 tracks, and loaded them up into Jaikoz. I then created Acoustic IDs and run Musicbrainz Autocorrect, then spend a few hours correcting and cleaning up. (I have a lot of obscure titles and compilations which Musicbrainz doesn't handle too well.)

Then tried running Save Changes and get the above error, apparently on all files. No changes at all seem to have been saved. "Because null" is not very illuminating.

Two questions:

1) possible ways to fix this?

2) how to temporarily save my current set of edits somewhere (hours of work there!) so they can be reapplied after I figure out how to deal with the save issue, in case I need to restart Jaikoz, the local Mac host, or the server running the share?

Large collection on home server includes 80% my stuff all ripped to FLAC, and 20% wife and son's stuff, variously in Apple Lossless and MP3.

None of us use iTunes now (Sonos mainly, and Cog and MediaMonkey on individual PCs).

I would like to reduce the number of formats to keep file and metadata management a bit simpler, and thus want to convert the Apple Lossless files to FLAC.

Anyone with advice on how best to do this, and how to preserve tags while doing so? Also, will doing this confuse Jaikoz in any way?

Paul - Thinking further about your suggestion here, another question arises.

The procedure you outline will clearly end up with album art in folder.jpg files and out of individual track tags/metadata, as I desire.

However, I have nearly 17,000 tracks. Most are already tagged but a with fair amount of errors, which I am looking to Jaikoz to help me sort out efficiently.

Probably 85-90% of my tracks currently reside in folders correctly grouped by album, and already have album art in place in a folder.jpg file as desired.

Using the step-by-step procedure you suggested will entail downloading a very sizable volume of album art data. I fear that this downloading will be done redundantly for each file in an album, which for a few hundred tracks wouldn't be too burdensome, but for thousands and thousands of tracks seems pretty daunting.

I would like to avoid all this downloading in those cases where I have album art already, but I still have the problem of re-doing paths for folder.jpg files if I use Correct Subfolder from Metadata.

Will something like this do the job?

1. Local Correct:Artwork Correct (To get my current folder.jpg artwork from files into tags. But how does this handle cases where no folder.jpg exists?)
2. (Auto)Correct Metadata from Musicbrainz (Assume there a prefs setting which will download artwork only where missing, yes?)
3. Probably best at this stage to review and hand edit/correct where needed
4. Save Changes
5. Correct SubFolder from Metadata
6. Save Changes again
7. Save Artwork to Filesystem
8. Empty Column to remove artwork from Files.
9. Save Changes again

If this (or something like it) would work, is it likely to save me significant time and bandwidth burden over your previous suggestion?

thanks Paul, that sounds like it end me up where I want to be.
New user here, still working my way through the manual and doing a little beginner experimentation, in preparation for a planned complete tag cleanup of my 15,000+ track collection, including mix of FLAC, MP3, other. All resides on a Linux SMB/CIFS share on my home LAN.

I will first do Acoustic IDs for all tracks, then do Musicbrainz Autocorrect or Manual Correct, working in chunks, maybe a few dozen albums per night, since I anticipate needing to check and fine-tune a fair amount.

My collection is played 99% only on Sonos, and I don't need or want album art in each file, but must have in a folder.jpg file in each album folder. At present, I have only around 60% of needed art in place.

I can't quite figure out how to set the prefs so that Autocorrect or Manual Correct will only put album art where I want it. Can this be done?

Also, after I have corrected all tags, I plan to redo the path to each album folder based on the cleaned up metadata.

Will the "Correct subfolders from metadata" action also redo paths to the accompanying folder.jpg files along with the tracks?

Profile for bobm -> Messages posted by bobm [21]
Go to:   
Powered by JForum 2.1.6 © JForum Team