-
Notifications
You must be signed in to change notification settings - Fork 425
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retrieve tags from Bass tracks when available #5627
Conversation
/// <summary> | ||
/// The ID3 tags contained in this track's metadata. | ||
/// </summary> | ||
Tags? Tags { get; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm really not sure if we want this on Track
. Especially so if it's going to not be implemented for anything but TrackBass
.
Alternative would be something like
public interface ITaggedTrack
{
Tags Tags { get; }
}
which could only be applied to TrackBass
, but that likely causes trouble with DrawableTrack
(the inner track is private, so you wouldn't be able to access the tags otherwise).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made sense in my head as tags can be present on the track regardless of implementation (Bass or otherwise).
DrawableTrack
's inner track could probably be public since it's already readonly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, but layering wise I'm not sure it fits smack dab in the middle of the rest of the audio subsystem.
I'm just mostly pondering. Need more opinions on this for sure before proceeding in any particular direction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember there being an overhead with tag retrieval, in stable it’s only requested in the editor to avoid this.
Will need to check if this is still the case.
On actually inspecting the code, it looks to be on-demand so this shouldn't be an issue.
if (string.IsNullOrEmpty(parsed.Artist)) | ||
parsed.Artist = tags.AlbumArtist; | ||
|
||
if (Int32.TryParse(tags.BPM, out int bpm)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (Int32.TryParse(tags.BPM, out int bpm)) | |
if (int.TryParse(tags.BPM, out int bpm)) |
Also what's the guarantee that this is gonna parse as int
? What about fractional BPM?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hadn't considered that, on second thought not even sure this is worth having because it doesn't seem to be populated very commonly.
Also please check code style. |
Co-authored-by: Bartłomiej Dach <[email protected]>
@@ -23,6 +23,8 @@ public abstract class Track : AdjustableAudioComponent, ITrack, IAudioChannel | |||
|
|||
public virtual bool Looping { get; set; } | |||
|
|||
public Tags? Tags => GetTags(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're going to go as far as having a property, it should probably cache so they are only retrieved once.
…editor - Closes ppy#21189 - Supersedes / closes ppy/osu-framework#5627 - Supersedes / closes ppy#22235 The reason why I opted for a complete rewrite rather than a revival of that aforementioned pull series is that it always felt quite gross to me to be pulling framework's audio subsystem into the task of reading ID3 tags, and I also partially don't believe that BASS is *good* at reading ID3 tags. Meanwhile, we already have another library pulled in that is *explicitly* intended for reading multimedia metadata, and using it does not require framework changes. (And it was pulled in explicitly for use in the editor verify tab as well.) The hard and dumb part of this diff is hacking the gibson such that the metadata section on setup screen actually *updates itself* after the resources section is done doing its thing. After significant gnashing of teeth I just did the bare minimum to make work by caching a common parent and exposing an `Action?` on it. If anyone has better ideas, I'm all ears.
…editor - Closes ppy#21189 - Supersedes / closes ppy/osu-framework#5627 - Supersedes / closes ppy#22235 The reason why I opted for a complete rewrite rather than a revival of that aforementioned pull series is that it always felt quite gross to me to be pulling framework's audio subsystem into the task of reading ID3 tags, and I also partially don't believe that BASS is *good* at reading ID3 tags. Meanwhile, we already have another library pulled in that is *explicitly* intended for reading multimedia metadata, and using it does not require framework changes. (And it was pulled in explicitly for use in the editor verify tab as well.) The hard and dumb part of this diff is hacking the gibson such that the metadata section on setup screen actually *updates itself* after the resources section is done doing its thing. After significant gnashing of teeth I just did the bare minimum to make work by caching a common parent and exposing an `Action?` on it. If anyone has better ideas, I'm all ears.
For use in ppy/osu#21189. Only retrieves a subset of all the tags read by Bass that seemed relevant to osu!.