Winamp 5.7 Beta 13, build 3444 (with Winamp Cloud Beta)

[DJ Egg]

As far as I know, ml_downloads only gets installed alongside Online Services (ml_online.dll) & Podcast Directory (ml_wire.dll).
As Chris000001 installed Online Services, that is why ml_downloads.dll exists.
Online Services such as MP3 Of The Day would use it to download files.

[DJ Egg]

@MrSinatra

Yes, it's kind of the same thing, though Ctrl+E in the Playlist Editor (in winamp.exe) is for the Edit Playlist Entry dialog,
whereas Ctrl+E in ml_local is for the ML Edit Metadata dialog.

Positions for both are now saved anyway.

Re: in_mp3/id3 tags

It might have something to do with the ID3v1 genre issue,
though to be perfectly honest, I couldn't reproduce that issue before the changes, and I still can't.

However, whilst trying to reproduce it, I noticed some other more pressing issues...

When editing field values in an ID3v1 tag, I noticed that the ID3v2 tag and Basic Info tab info were also being updated.

Now, I remember the days when ID3v2 tags were seen as the spawn of Satan,
but these days, I very rarely ever use or look at ID3v1 tags anymore.

Before we implemented the unified tag editor in v5.5, ID3v1 and ID3v2 tags were both in the same single window in the MP3 tag editor.
When you edited ID3v1 values, the ID3v2 tag didn't get auto-updated.
And when you edited ID3v2 values, the ID3v1 tag didn't get auto-updated.
There was a "Copy to ID3v1" button in the ID3v2 section, and a "Copy to ID3v2" button in the ID3v1 section.
Those buttons are still there in the newer unified editor.

So, because I'm pretty certain that editing an ID3v1 tag shouldn't auto-update an existing ID3v2 tag,
if an ID3v2 tag exists then it should always take precedence over ID3v1 (and APEv2 or Lyrics3 tags).
Therefore, the info in the Basic Info tab should not be updated unless you also edit the ID3v2 tag.
If there's no ID3v2 tag, then yes, when you edit an ID3v1 tag, the Basic Info tab should also update along with the metadata displayed in the Playlist Editor etc.

Only when you edit metadata in the Basic Info tab should both ID3v1 & v2 tags be updated (as long as the relevant setting is enabled in in_mp3 config)

Agreed?

Hope that all makes sense, btw.

[jph6t]

Genre drop-down in the “File Info” window is NOT populating correctly for FLAC files

Winamp 5.7 Beta 7, build 3381 to 3392 changelog
- [in_flac] Possible fix for jph6t's FLAC genre issue

I just installed Beta 7, build 3392.
No joy. I'm still getting the same issue with how the genre displays for FLACs.
I'll take further conversation on the topic to the dedicated thread on the FLAC genre issue.

[Chris000001]

that is expected (though annoying) behaviour. if you use the up arrow key when on the components then it'll take you back to your previous install.

without checking, it's likely due to it being used for some of the general download handling of files within the library so it can end up being installed when maybe it's not needed to be cautious. am sure Egg or I will check it out and adjust the installer as needed if it's really not needed based on your install.ini.

As far as I know, ml_downloads only gets installed alongside Online Services (ml_online.dll) & Podcast Directory (ml_wire.dll).
As Chris000001 installed Online Services, that is why ml_downloads.dll exists.
Online Services such as MP3 Of The Day would use it to download files.

Thanks. I thought default "custom" in the installer was the same as "previous", since the only thing that seems to change is detector for IE. And, thanks for the explanation of why ml_downloads is installed. I only use ml_online for shoutcast radio.

[MrSinatra]

@MrSinatra

Yes, it's kind of the same thing, though Ctrl+E in the Playlist Editor (in winamp.exe) is for the Edit Playlist Entry dialog,
whereas Ctrl+E in ml_local is for the ML Edit Metadata dialog.

Positions for both are now saved anyway.

ah, I see. it didn't say playlist editor for either one though. if its meant for the first one, is alt+3 saved for ml_local?

I've kinda lost track.

nevermind, I just tested it, both work where I use em. interestingly, alt+3 is the same for either, and either saves the same location, (cool!) but ctrl-E seems to be a different function, depending on where u do it from [ml or playlist].

Re: in_mp3/id3 tags

It might have something to do with the ID3v1 genre issue,
though to be perfectly honest, I couldn't reproduce that issue before the changes, and I still can't.

sure would be nice to have a step by step procedure to see who can and can't and try to figure out why.

However, whilst trying to reproduce it, I noticed some other more pressing issues...

When editing field values in an ID3v1 tag, I noticed that the ID3v2 tag and Basic Info tab info were also being updated.

that definitely seems problematic to me. I would think the v1 tab, and the v2 tab, would NOT impact each other. and I would assume the basic tab would always follow the v2 tabs lead, (assuming a v2 tag was present, even if blank). of course, winamp merges tag levels, which I think is a bad idea. (meaning, if v1 has a track number and v2 doesn't, but has other stuff v1 has, the v2 stuff is used PLUS v1's track number.

a good pref would be to disable such tag merging in winamp.

but anyway, obviously both tabs should follow the basic tabs lead, when basic is being used. with v1 however, it will always be limited by design, and not be able to do what the basic tab says, like genres outside its dopey default list, or strings longer than 30 chars, etc... so you can't have pure harmony between all the tabs.

Now, I remember the days when ID3v2 tags were seen as the spawn of Satan,
but these days, I very rarely ever use or look at ID3v1 tags anymore.

indeed. you are showing your age! these days, v1 is obsolete/legacy, v2 is king. I strip all v1 stuff to avoid these issues, and that explains why I haven't seen this. winamp should still support v1 of course, but imo, unless u need them for some reason, like old gear, kill em.

Before we implemented the unified tag editor in v5.5, ID3v1 and ID3v2 tags were both in the same single window in the MP3 tag editor.
When you edited ID3v1 values, the ID3v2 tag didn't get auto-updated.
And when you edited ID3v2 values, the ID3v1 tag didn't get auto-updated.
There was a "Copy to ID3v1" button in the ID3v2 section, and a "Copy to ID3v2" button in the ID3v1 section.
Those buttons are still there in the newer unified editor.

sounds right to me. they should not impact each other. while it could lead to divergence and so on, that's unavoidable anyway, given v1's limitations as noted above.

btw, this raises another bug I noted many months back. if you disable winamps ability to create id3v1 tags, that works, EXCEPT when you hit the "copy to v1" button. now, imo, if you disable v1 creation in the plugin, you probably should not be able to over-ride that via that copy to v1 button, but I let it go b/c it is kinda a handy hacky workaround should someone ever need to create a v1 tag who otherwise has it disabled. I leave it to you to decide how to handle that lil bug.

So, because I'm pretty certain that editing an ID3v1 tag shouldn't auto-update an existing ID3v2 tag,
if an ID3v2 tag exists then it should always take precedence over ID3v1 (and APEv2 or Lyrics3 tags).

take precedence where? alt+3? the ML? I agree in both cases. (I strip apeV# and lyrics too btw)

as I said above, its confusing to this process to merge tag layers. the basic tag should show only the top most layer imo.

Therefore, the info in the Basic Info tab should not be updated unless you also edit the ID3v2 tag.

but what if you purposely keep them divergent? i'm kinda confused by what you are saying here, b/c v1 and v2 will often not be the same, yet close to the same.

If there's no ID3v2 tag, then yes, when you edit an ID3v1 tag, the Basic Info tab should also update along with the metadata displayed in the Playlist Editor etc.

sounds reasonable, but I would not have the basic tab apply any changes to file UNLESS someone actually changed something on that tab. but having it visually update to reflect v1 (if only v1 is present) or v2 (if present) would probably eliminate possible user confusion.

Only when you edit metadata in the Basic Info tab should both ID3v1 & v2 tags be updated (as long as the relevant setting is enabled in in_mp3 config)

Agreed?

Hope that all makes sense, btw.

I definitely agree that the basic tag should update both v1 and v2, but again, v1 is limited, esp with genres. it can't do any that aren't in its default list. v1 has no albumartist or some other tags, and displays track#s different, truncates strings, etc... while v2 can do everything you can do in basic, v1 can only approximate it.

btw, I would like to see the same things in the same place between basic and v2. the layout is different. move the check marks to the bottom, and get the fields all aligned in the same order between basic and v2 (and v1 to the extent possible). I like the v2 layout mostly, and would copy the others to it, (but move BPM up like in basic).

one last thing... any chance you will include the TCMP frame (compilation) to the ML? allow edits?

[ujay]

Just out of interest.

Are Extended/Lyric3 tags still read by Winamp, or has that been completely dropped now ???

UJ

[Batter Pudding]

Just out of interest.

Are Extended/Lyric3 tags still read by Winamp, or has that been completely dropped now ???

UJ

Wasn't that always just a plug-in?

[ujay]

There were two plugins, in fact, BP.
One to display the lyrics and slide shows etc. and one to embed them in the file.
I liked it as a system very much, but it broke when Winamp went multi user.

Lyric3 was embedded as an extended area placed immediately before the Id3v1 block.
Another feature was the ability to extend the Id3v1 tags beyond the 30 char limit, this was what Winamp itself could access without the plugin and used to be displayed in 'View file info'.

I need to find something that still has lyric3 tags and see what the latest versions make of it.

UJ

[Aminifu]

Before we implemented the unified tag editor in v5.5, ID3v1 and ID3v2 tags were both in the same single window in the MP3 tag editor.
When you edited ID3v1 values, the ID3v2 tag didn't get auto-updated.
And when you edited ID3v2 values, the ID3v1 tag didn't get auto-updated.
There was a "Copy to ID3v1" button in the ID3v2 section, and a "Copy to ID3v2" button in the ID3v1 section.
Those buttons are still there in the newer unified editor.

So, because I'm pretty certain that editing an ID3v1 tag shouldn't auto-update an existing ID3v2 tag,
if an ID3v2 tag exists then it should always take precedence over ID3v1 (and APEv2 or Lyrics3 tags).
Therefore, the info in the Basic Info tab should not be updated unless you also edit the ID3v2 tag.
If there's no ID3v2 tag, then yes, when you edit an ID3v1 tag, the Basic Info tab should also update along with the metadata displayed in the Playlist Editor etc.

Only when you edit metadata in the Basic Info tab should both ID3v1 & v2 tags be updated (as long as the relevant setting is enabled in in_mp3 config)

Agreed?

Hope that all makes sense, btw.

I think I understand most of the above.

I have enabled all 6 of the configuration options on the in_mp3.dll ID3 Tags tab. I have also selected "System Language" for reading ASCII tags and "Unicode (UTF-16)" for writing tags. Do I need to enable both the tag writing and the tag creation options? What is the difference between these two categories?

I normally use the Basic Info tab for editing mp3 metadata, unless it is the genre tag. For genre updates, I use both the Basic Info and the ID3v1 tabs. I never use the ID3v2 tab because I don't use the additional tags shown on that tab. Would it be better to use the ID3v1 and ID3v2 tabs instead of the Basic Info tab for editing?

[DJ Egg]

I think I understand most of the above.

I have enabled all 6 of the configuration options on the in_mp3.dll ID3 Tags tab. I have also selected "System Language" for reading ASCII tags and "Unicode (UTF-16)" for writing tags. Do I need to enable both the tag writing and the tag creation options? What is the difference between these two categories?

I normally use the Basic Info tab for editing mp3 metadata, unless it is the genre tag. For genre updates, I use both the Basic Info and the ID3v1 tabs. I never use the ID3v2 tab because I don't use the additional tags shown on that tab. Would it be better to use the ID3v1 and ID3v2 tabs instead of the Basic Info tab for editing?

ID3 Tag Writing options are for modifying existing tags (e.g. when using Edit Metadata in ML or the Basic Info tab)

ID3 Tag Creation options are for when creating new files (e.g. with CD Ripper or Transcoder)

I only ever use the Basic Info tab for editing these days.
I couldn't really care what's in the ID3v1 tag.
Any devices/players which don't support ID3v2 are either very old, crappy, or both.
But yeah, the Basic Info tab will update both, so that is good enough for me.


@ujay

Lyrics3 tag reading should still be working.

in_mp3 > config > APEv2 & Lyrics3 > Read Lyrics3 tags.
If a Lyrics3 tag exists, then it should be displayed, as long as there's no ID3v2 tag.
I think APEv2 also takes precedence over Lyrics3?

Order of precedence = ID3v2, APEv2, Lyrics3, ID3v1

Alas, I'm not even sure what "Extended Lyrics3" tags are.
Some 3rd-party plugins provided support for them, right?
Are said plugins dead/broken?

[djpete]

go up and down the tree in media library in the new beta and you will see a slight flicker in the name you chose. This is not there in other versions. Just thought I would mention in case its a prob down the track. Only slight but definitely there for me. Build 3392.

[ujay]

Hi Egg.

I haven't been in there for years ... spooky

Things seem to have changed since I last did anything with this, as I remember it, there was a Lyric3 tab in the Basic Info window.

Strictly speaking lyric3 is an extention of the Id3v1 spec. and adds 3 extra sets of tags to what is already in the Id3v1 block.

These are :
Extending the length of the 30 char. fields that are already in the Id3v1 tags.
Embedding lyrics.
Embedding images.

From what I remember, Winamp can only natively read the extended fields, you will need a plugin to do anything else.
This means that Winamp cannot write anything to these tags and their main use would be in transferring the info from the extended fields to Id3v2 tags.

The only real problem I remember was if you deleted the Id3v1 tags, as this would leave the Lyric3 tags floating. Not a problem for Winamp as it appears to be able to find the required chunk by inspection and not by reference to the Id3v1 block itself. However, this will probably break the file for use with other readers/plugins.

UJ

[Aminifu]

ID3 Tag Writing options are for modifying existing tags (e.g. when using Edit Metadata in ML or the Basic Info tab)

ID3 Tag Creation options are for when creating new files (e.g. with CD Ripper or Transcoder)

I only ever use the Basic Info tab for editing these days.
I couldn't really care what's in the ID3v1 tag.
Any devices/players which don't support ID3v2 are either very old, crappy, or both.
But yeah, the Basic Info tab will update both, so that is good enough for me.

Thanks for the info on the in_mp3.dll ID3 Tag Writing and Creation options.

One of my mobile mp3 players is very old and only reads ID3v1 tags. It still works very well, so I take advantage of Winamp's ability to write v1 and v2 tags. I'm content with how the Alt+3 editor is working in version 5.7.3392, i.e. it provides the ability to edit mp3 ID3v1 and ID3v2 tags separately.

If I'm the only one sometimes seeing a discrepancy on the ID3v1 tab for what is in a file's v1 genre tag, then it must be unique to my Winamp configuration. When I see the wrong value, I'm able to verify outside of Winamp (with various 3rd party taggers) that the correct value is actually in the file.

If I do not touch the box showing the wrong value before clicking the "OK" button (or change it to the correct value), then the correct value in the file is not changed (or is updated to the same value). Before version 5.7.3382, I had to select the correct value before clicking the "OK" button (or the wrong value was written to the file). I'm glad this minor annoyance is not affecting others. I had learned to live with it and it's only a single v1 tag, after all. The vast majority of the time, I use the ID3v2 tags with Winamp and with all my other mobile mp3 players.

I first mentioned it last January and only mentioned it again because it seemed similar to the issue jph6t is having with his flacs.

[MrSinatra]

I am glad you mentioned it and I am glad it is being addressed, b/c this is basic fundamental functionality and winamp should be as bulletproof as possible, even for something obsolete like v1 tags.

however, it would be good if you would take the time to provide step by step method for reproduction, so all could see if they can see what you see. when I test jph6t's issue, using his steps to, I can not reproduce it. I believe he has it, but this suggests only he has it, or its unique to him/his settings in some way, esp if others test and confirm my results.

your issue may now, as of the latest beta, be only "visual" as opposed to functional, (depending on what someone clicks or not), but it should still be fixed if others can do what you do, and see what you see. of course, that's contingent on knowing that others are taking the same steps to reproduce, and can in fact reproduce.

[Aminifu]

your issue may now, as of the latest beta, be only "visual" as opposed to functional, (depending on what someone clicks or not), but it should still be fixed if others can do what you do, and see what you see.

The Alt+3 tag editor does not need further modification (maybe it never needed any).

Taking jph6t's lead, I ran Winamp in safe mode and the editor worked correctly. I tracked the interfering plug-in to "gen_os_diag.dll". This is one of DrO's plug-ins (no longer available) that allowed certain Winamp dialogs to remember their screen positions from session to session.

It's weird, imo, but something in that plug-in prevents the editor's ID3v1 tab from displaying the v1 genre data in the file. Fortunately, the major Winamp dialogs now remember their screen positions natively, so I don't really need this plug-in anymore.

I use, and have come to depend on, several of DrO's plug-ins. I should have tried safe mode sooner, but I guess I didn't want to believe that one of DrO's plug-ins could have been involved. I had tried removing all my 3rd party plug-ins developed by other people.

This incident in no way changes my confidence in DrO's abilities.