Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Quisp]

As requested by Jim, I've started a new thread about what I feel is a production limitation with Tagging Mode.

Here is how I currently tag:

1. I create a small "dummy" mp3 file and apply a single genre to it as well as every style available in the All Music Guide which I store in a custom field called "Sub-Genres". I do this so I have access to all possible Sub-Genres whether I've used them or not.

2. I then create a view consisting of Genre/Sub-Genre/Artist Sort (I have another view which removes the dummy files from the list so I can see Sub-Genres that I'm actually using...)

3. I can then go into Tagging mode to apply Sub-Genres to artists.

The problem is that everytime I click on a single Sub-Genre, the new tag info is saved to the selected files since I want the info saved to the file. It can sometimes take over a minute to apply 4 or five sub genres since I've got a fairly large collection of music.

The solution for me would be to be able to apply multiple changes to tags at once, however this isn't a feature of MC. Other than typing this stuff out by hand, is there a better, i.e. faster way to do this?

I have similar issues with the Action window, too much action

[nila]

There have been a few posts about this recently.
gkerber for one is DEFINITELY agreeing with you strongly.

I did my first tagging today in ages and instantly got hit by the problem your talking about.
Each change results in the tags being updated so if we're doing lots of tag changes the file is being re-written tons of times. With mp3's with id3v2 tags - isn't the tag stored at the front meaning that MC is re-writing the whole mp3 for each and every field we change?
I have full faith in MC's ability to handle the files but making it have to write them 5 times more than necessary just really seems like putting it fully to the test - I prefer safe than sorry and I'd rather it was just changed once for all the changes.

Maybe as has been suggested - an 'Apply' button.

I'd suggest an option to let users have it done automatically or let them have to 'apply' it but no options seems to be the rule (registry options are always a nice second choice!!)
At least that way it's up to us if somewhat tricky.


The biggest problem is that sometimes I lilke it auto doing it - when I'm working with my collection (just chosing songs to play) and just want to quickly change one thing.

When I'm doing proper tagging though - this is when it becomes a pain!

Maybe link it's behavior to tagging mode or something?

[NoCodeUK]

I had a similar problem last week.  I tried to create a field called decade where I could store the decades that an artist was actively making music.  I wanted it to be a list type and to be able to apply multiple options per artist but could not find a way to do it and so gave up...

Adam

[Matt]

We're not sure what the "right" time to synchronize the library and tags is so we synchronize everytime a change is made.  We don't want an apply button.

If someone has a good solution for when to automatically synchronize, we'll change it.  Again, no options or buttons -- there's no reason a user should have to worry about that.

Thanks for helping.

[gkerber]

We're not sure what the "right" time to synchronize the library and tags is so we synchronize everytime a change is made.  We don't want an apply button.

If someone has a good solution for when to automatically synchronize, we'll change it.  Again, no options or buttons -- there's no reason a user should have to worry about that.

Thanks for helping.

There is always a compromise between user actions and automatic actions.  Automatic is good when it makes sense.

Having a Commit/Ignore button in the ActionWindow when showing properties would be confusing I think since the properties always show, there is not a definate "end" to that display.

But having a Commit/Ignore button in Properties when undocked makes perfect sense, and MC had it in a prior incarnation of MC.

In undocked, the Commit should occur when:

1.  The Commit button is pressed.
2.  The properties window is closed.
3.  The record shown changes by user action (like pgup/pgdn).

There is no real "worry" about an Commit/Ignore button, since the action is automatic when the undocked window is closed or .... (as described above).

If someone has a good solution for when to automatically synchronize, we'll change it.

Here you go, here is the good solution, when will it be changed?  <g>

[Matt]

Sorry, but solutions that only work for one of the two main Action Window modes (docked vs. undocked) aren't ideal.

Version 9.0 synchronized each time the list selection / tree selection changed.  Maybe that's better than how it is now...

[gkerber]

Sorry, but solutions that only work for one of the two main Action Window modes (docked vs. undocked) aren't ideal.

In a perfect world.....  I have no idea of the coding involved (I hate when users tell me they want a change and "it's simple").  I see no un-ideal problem with undocked providing more control than docked, undocked shows more, that makes it easier, so what's wrong with controlling a commit differently?

Version 9.0 synchronized each time the list selection / tree selection changed.  Maybe that's better than how it is now...

I find the current way a bit non-intuitive in docked mode.  I change a value, but the commit does not occur until I click out of the field.  Of course, there must be some "event" to trigger the update and losing focus on the edited field seems correct, else you woud end up commiting every keystroke, really slowing things down.

Well anyway, your program, your choices, thanks for listening.

[nila]

We're not sure what the "right" time to synchronize the library and tags is so we synchronize everytime a change is made.  We don't want an apply button.

If someone has a good solution for when to automatically synchronize, we'll change it.  Again, no options or buttons -- there's no reason a user should have to worry about that.

Thanks for helping.

Hey Matt, glad to see your open to discussion on this one.

u say there's no NEED for a user to have to worry about it - what if we want to thou? Alot of times in life it's about what people want rather than need  

I know your trying to find a balance for everyone though and maybe your worried that will intimidate beginners or something.
I know from some of my friends though that sometimes beginner users find a button to do something comforting - they are reassured that nothing is going to happen until they push it. Or if they're worried I often just tell them (not with MC - with other software at present) - play as much as you want - if u dont like it - just dont do blah.
Anyway - ur call so no worries

How about just they're not applied until the user clicks OFF the detailed info screen?
If they tab between fields - no changes applied - if they click on another field inside of it - no changes - if they click outside of it then the changes are applied?

That seems like the best solution to me

[Quisp]

Wow, Matt, I respectivly disagree, in fact, applying changes to data is exactly when I, as a user, should make the decisions, not a third-party.

To address Nila's point about sometimes liking it to auto save (I do too...), a key modifier would work great, in other words...

1. Change artist to blah, blah, create sort field, update genre, add sub-genres, get image from internet, apply changes (either through telepathy or selecting an "Apply" button)...Wait a few seconds for all changes to be applied at once.

2. Make a change to Title, Ctrl Alt Tab to new field to Apply change or Ctrl Alt click to change focus and apply change, etc.

A useful exercise would be to load up MC with 15,000 files or so and begin to tag them very deliberalty with goals in mind (salaried people only please  ). I think you'll find that a better solution needs to be forthcoming.

If you really are against users making desicions about when their data is changed, then at least in Tagging mode, saving data only if I change any value that isn't in the current pane, would be less of a pain.

For instance, for a view such as Genre/Sub-Genre/Artist

I'd select the files by an artist , check off all desired Sub-Genres and then if I selected another artist or any other pane, or the action window, etc., the changes would be saved.

I think it makes sense to save automatically if I'm in a part of the interface where I'm only able to perfom one change, right click mode, Tools menu, etc, but in the AW and in Tagging Mode, it is extremely tedious to use MC's extremely tremendous organizational tools.

[Quisp]

Nila got his response in while I was typing mine...

Ditto...

[skeeterfood]

How about:
1) Hitting enter in a field commits immediately
2) Tabbing/Mouse clicking between fields uses 9.0's concept of only commiting the changes when the selection/tree changes.

-John

[hit_ny]

I am completely ignorant of tagging mode.

Way i tagged my stuff relied heavily on the action window.

if i had a bunch of files to tag, i selected them all, went to the action window and if it was a mass tag, just entered in the relevant field.

if i need  to edit a particular field. click the field and F2, its done.

This is all seemed quite intuitive.

What will tagging mode offer me over the previously described method ?

[Bartabedian]

Seems to me the bigger issue here is the way the tags are written. It's totally inefficient, and in my experience the absolute slowest tagging app I've ever used. It's what prompts me to use the tagging features in very rare instances. I've posted about this before, that speed needs to be improved radically.

[gkerber]

I am completely ignorant of tagging mode.

Way i tagged my stuff relied heavily on the action window.

if i had a bunch of files to tag, i selected them all, went to the action window and if it was a mass tag, just entered in the relevant field.

if i need  to edit a particular field. click the field and F2, its done.

This is all seemed quite intuitive.

What will tagging mode offer me over the previously described method ?

Everytime you update a field in the action window, it updates all the records affected.  If there is only a few, you may not notice the update time.  

If you had selected zillions of records and wanted to update 2 or more fields, this update/save cycle can become tedious.

You update one field, it *updates a zillion files, you update the next field, it updates the same zillion files again.  Do this to a few more fields, and you'll see what we mean by tedious.

*updating a zillion files has to ask you "are you sure" and then takes lots of time.

[Matt]

This has been addressed in 9.1.246.  Hopefully it's a workable solution.

Seems to me the bigger issue here is the way the tags are written. It's totally inefficient, and in my experience the absolute slowest tagging app I've ever used. It's what prompts me to use the tagging features in very rare instances. I've posted about this before, that speed needs to be improved radically.

Can you give any more details? (maybe start a new thread so we can figure it out)  Tell us the format, ID3v2 vs. ID3v1, how you're benchmarking, etc.

ID3v2 should only be first slow during the first save and then once it's there and padded minor changes shouldn't be slow.

JPEG and APE tagging are both super fast for me.

Thanks.

[hit_ny]

maybe i am missing somethgin here....

if i recall correctly, doing a tag for he first time does indeed take a long time...i assumed that was because they were tag2 fields being written.

However if the tag2 fields have already been written an i want to do a mass change, it seems to go by pretty quick, (eg  100 files in say 5-10s)

Now what i have not done is play with custom fields, if i were to do that, i would expect it to take a long time, as its writing another (new field).

have i understood you correctly

[fex]

...ID3v2 should only be first slow during the first save and then once it's there and padded minor changes shouldn't be slow....

Exactly my experience. Only the first save is during some time. The following ones are done in one or two seconds (changing a few hundered files). So this is not really a problem for me.

[Quisp]

The new version's solution is workable for me, thanks Matt!

However, one thing I am noticing in Tagging Mode is that for each Sub-Genre I click there is a minimum 5 second pause before it is selected. The Sub-Genre field is a custom list field with a few hundred values. I realize that is a ridiculous amount and I intend to tweak it later, but I wonder what is going on between the click and the screen draw.

[fex]

...The Sub-Genre field is a custom list field with a few hundred values...

Funny, never thought that it would be so slow with ONLY a few hundred values  . In just one field .

[Quisp]

Really!  

[StFeder]

The mp3 Tag Studio of Magnus Brāding (http://www.magnusbrading.com/mp3ts) has THE solution for this:
It offers a option, wich can be either checked or not (nice option, isn't it  ), wich ONCE rewrites the complete file and changes the ID3v2 Tag location from the beginning of the file to the end. Works fine.
I didn't find a programm wich doesn't understand this sort of Tags (MJ, MC, Winamp, WMP).
Please read the following quote. It's out of the helpfile, wich offers information about this option:

Super fast v2 tagging:
When you write an ID3v2 tag to a file that does not have a previous v2 tag (or that has a smaller v2 tag than the one you are about to write), that whole file, including all sound data, must be rewritten to the disk. This is due to technical limitations in harddisk filesystems in combination with design issues of the ID3v2 tag, and there's nothing I (or anyone else) can do about it. The problem is that this might lead to several megabytes of data being written to the disk, even though the new tag data only consists of, say, a few hundred bytes. This in turn will of course affect the time of the write operation quite seriously. Due to this limitation, writing ID3v2 tags to files often takes much longer than writing ID3v1 tags to them. Normally that is...

When you activate this setting, you agree to sacrifice a very short bit of sound data (approximately 0.03 seconds) in the beginning of every file the first time you add a v2 tag to it, and in turn the operation will be just as lightning fast as writing an ID3v1 tag! There might be some reasons for why you don't want to do this in some situations (e.g. if the music of the track actually begins within the first 0.03 seconds of the mp3, but this is mostly not the case), and that's why I made it optional. But for doing ID3v2 tagging on e.g. a network drive or other slow media it is a lifesaver, I assure you. Just try it and you'll see what I mean...

[hit_ny]

When you activate this setting, you agree to sacrifice a very short bit of sound data (approximately 0.03 seconds) in the beginning of every file the first time you add a v2 tag to it, and in turn the operation will be just as lightning fast as writing an ID3v1 tag! There might be some reasons for why you don't want to do this in some situations (e.g. if the music of the track actually begins within the first 0.03 seconds of the mp3, but this is mostly not the case), a

Eh ? what was that about losing 0.03 seconds of sound for a faster tag re-write.

i sincerely hope that media center does not do this or plan to do so w/o sufficient warning.

Given a choice between waiting a bit longer for a tag2 write, which really is a one off anyway and losing sound data, i would pick waiting longer anytime.

Well, if i have any tracks that are mixed, this will defnitely be an issue, so i opt to go with cue files. Of course MC still does not recgonise cue files, but i am hoping they will be more receptive once bigger issues are taken care of.

[StFeder]

Eh ? what was that about losing 0.03 seconds of sound for a faster tag re-write.

I see what you meen. I just deleted 0.03 seconds of an audio file and this does quiet much effect. I didn't know that in such a short time so much sound can be played... (thank you hit_ny for opening my eyes).
But the idea isn't bad. Isn't it possible to change the tag-location without losing the sound?

[KingSparta]

It offers a option, wich can be either checked or not (nice option, isn't it  ), wich ONCE rewrites the complete file and changes the ID3v2 Tag location from the beginning of the file to the end. Works fine.

thats because it is ID3v2.4 and they can be anyplace in the MP3. nothing new and 2.4 has been out for 2 or more years. there is very few Jukeboxes that write Id3v2.4 tags.

[KingSparta]

I see what you meen. I just deleted 0.03 seconds of an audio file and this does quiet much effect. I didn't know that in such a short time so much sound can be played... (thank you hit_ny for opening my eyes).
But the idea isn't bad. Isn't it possible to change the tag-location without losing the sound?

I see no reason to do any mpeg triming, if you delete the Id3v2 and id3v1 tag and use a program to re-write the info back into a id3v2.4 tag no sound will be removed from the file.

years ago when ID3v1 was saved to a mp3 some programs did remove 128 bytes of info from the end of a file and replaced that 128 bytes with the tag info. if you then removed the id3v1 tag and then re-write it. some programs always removed another 128bytes of the mpeg and just did not tag this to the end of the file.

i think the reason for this was to keep the frame len the same and in fact it would create another problem by keep cutting off the end of the mpeg.

normaly th last frame of an mpeg is messed up and you can not count on it as being a good frame. mpeg checkers do not normaly check the last frame of an mpeg because of all the problems Id3v1 or id3v1.1 caused on how it was created and or removed.

there have been other tagging music match had there own that was a modified id3v1 tag near the end of the mp3 that sometimes confused jukebox programs including Media Jukebox.

triming off the last .5 seconds or so of the mpeg would normaly remove it.