Jump to content

Kundun

Approved Members
  • Posts

    61
  • Joined

  • Last visited

 Content Type 

Profiles

Forums

Blogs

Gallery

Downloads

Poweramp Knowledge Base

База знаний Poweramp

Poweramp知识库

Poweramp Equalizer Knowledge Base

База знаний Poweramp Equalizer

Store

Events

Ideas

Everything posted by Kundun

  1. +1 for considering MusicBrainz/Picard practices a little more (but still sticking to ID3 ofc).
  2. Yes, exactly what I was referring to, thank you for your effort for verbalizing it properly Andre!
  3. As I said I still consider adding a new sorting to other categories a better solution than to add new "Last Played *" categories or to add a grouping to the "Recently played" category. By adding a new "Last played" sorting + using the Reverse option a user could also see which (for example) albums he has never listened to or which album were played a long ago, something that you can't achieve by adding a new grouping in "Recently played". TBH a feature that I consider quite useful.
  4. Thank you for your attention Max, I don't want to hijack this thread and I don't know which solution OP suggests, but in this thread we already discussed some solutions. I haven't thought about a solution based on headings, I was thinking more of displaying the album instead of the tracks (maybe a checklist option with "Show album instead of single tracks"). For an example, let's assume the following is a screenshot of my "Recently played" category: After selecting the checkbox the result should be something like: Then you can have two possible solutions: The album view contains just the songs that you've listened recently (for example in shuffle mode) The album view contains the whole album This is of course just one of the possible solutions, I still consider adding the "Sort by recently played" sorting option to other Categories a better solution, at least compared to this one related to the "Recently played" category. We have thoroughly discussed the topic in this thread and several people manifested their interest over time, so I hope it takes a little traction
  5. We've already talked about a similar request here and similar remarks were arose. I don't still get @andrewilley 's take, of course we're playing just files with ID3 tags, so which is the point of using a music player instead of a file manager? An Album is an abstraction, but to stick to the just files paradigm seems reductive for a music player. If I put a CD on a physical player and listen to a single song, when was the last time I listened to that album? Those are just syntactical tricks, the user should decide if that's a useful feature or not, not a philosophical debate on if you listen to files or to an album. Plus this feature is implemented in most mobile music players (I remember it being the default sorting for Google Play Music in 2014). Really hope seeing this addressed in the 96X development cycle or in the future, it appears that I'm not the only one wanting it.
  6. +1 on this one, we already touched this topic here but the discussion didn't get much traction.
  7. Thanks Max for this update. Just a quick note, when rounded corners are disabled a left padding on the cover is preserved, is this the way intended to be? It looks rather strange UX-wise.
  8. I don't see the distinction here, do you mean that if I add some tracks of an album on the n day and then after that I add other tracks of the same album on the n+x day then the album will still be sorted as added on the n day? Isn't it how it should behave?
  9. From the Library home you can go in the Albums category and there from the 3-dots-menu you can select List Options -> Sort: by date added to Library
  10. +1, I always thought to have a toggle switch to disable rounded corner in the default skin as a good idea
  11. +1 on this, it's less intrusive as a solution
  12. A few days ago I was also thinking that showing the complete YYYY-MM-DD everywhere may result in a bloated UI, so maybe it's a better idea to show that in the Years category only (when a specific year is selected)? Or maybe make it toggleable?
  13. I still suggest to use TYER+TDAT as the preferable method, and TYER in the YYYY-MM-DD format as a fallback method, maybe using a priority list like the following: TYER+TDAT TYER YYYY-MM-DD TYER YYYY-01-01 Just to give a little bit of context on why I suggest to do so: From a metadata tagging point of view I am a Picard user, and what Picard does is to store the TYER (YYYY) and TDAT (DDMM) in a compliant way, even though the input field is just a single "date" field where you can put YYYY or YYYY-MM-DD (Picard will update TYER only or both TYER and TDAT accordingly to user input). From a desktop playing point of view I am an MPD (Linux) and Foobar200 (Windows) user, and both of them do recognize the TYER+TDAT combo properly. Those are just three examples of three popular apps (I mean, in their own niches) that do support the TYER+TDAT combo, so considering to use that as the preferable method (since it's id3 compliant too) is to me pretty logical, and having some sort of priority list like the one above (and by that covering more use cases) sounds like the right choice to me.
  14. The ability to specify a list of characters ('/', ';') or keywords ("ft.", "w/") to use as separators would be a nice addition. This can be useful for non-english users too, so a user can specify mit for German or con for Italian.
  15. Seemingly so simple? Several edge cases have been listed above, I don't see this feature as simple from an implementation point of view as a lot of users defined it to be honest.
  16. Hi there, I'm here to ask to support full date in sorting and grouping. If you have a tons of album from the same year it can be problematic to sort or group albums by year (plus this can be useful in the album view for artists with significant output in a single year, cfr. this). This can be implemented using the id3v2.3 tag TDAT or the id3v2.4 tag TDRC. A short summary (from id3 specification): TDAT:The 'Date' frame is a numeric string in the DDMM format containing the date for the recording. This field is always four characters long. TDRC: The 'Recording time' frame contains a timestamp describing when the audio was recorded. [...] The timestamp fields are based on a subset of ISO 8601. When being as precise as possible the format of a time string is yyyy-MM-ddTHH:mm:ss (year, "-", month, "-", day, "T", hour (out of 24), ":", minutes, ":", seconds), but the precision may be reduced by removing as many time indicators as wanted. Hence valid timestamps are yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and yyyy-MM-ddTHH:mm:ss. All time stamps are UTC. The TDAT tag was changed to the TDRC one in id3v2.4, but I suggest to support both of them (probably most of the time only one of those will be present, not both), since most of other players/taggers support only TDAT (probably due to parsing criticalities related to the variable timestamp length of TDRC). I myself use the TDAT tag only, it's just way more straightforward and more supported. If those fields are not present then a timestamp like "YYYY-01-01" can be inserted in the internal DB, as many others do in this case. I know that it will need a full rescan of the user music library to function properly, but by settings "YYYY-01-01" as the default timestamp this won't affect or break anything, since the fallback sorting will always be the alphanumerical order (as it is right now). Thank you for your job and have a happy new year! Related request: Choose Metadata Field for Year Сортировка альбомов
  17. I basically agree on everything you said, on the bullet separator too, so thank you for your contribution Andre
  18. So how can this be implemented effectively? Should we use a semicolon-separated list in the Artist tag and a general representive label in the Album Artist one? Let's take the 1977 album Cluster & Eno, composed by the homonimous musicians. Basically everywhere (RYM / Discogs / MusicBrainz) it is credited as it's titled (Cluster & Eno by Cluster & Eno), of course this isn't ideal, but what's the best solution to handle this case scenario? To just take the content of a single tag and split on ampersands is obviously a bad idea, since a lot of bands use them in their name (already highlighted by Andre), but without taking that in account this is also wrong since the album would be listed under Eno (insted of Brian Eno), creating a second inconsistency. So to just parse a single string is a suboptimal solution, and that's why I think that the combo solution with Album Artist/Artist tags is the way to go (of course I'm not reinventing the wheel, this is how a lot of players/platforms handles multiple artists), so for the sake of this example the artist tag of each track should be "Cluster; Brian Eno" and the Album Artist one "Cluster & Eno". It has already been said how the Album Artist tag can be considered an additional grouping condition, so this one to me seems the most-straightforward way to implement this use case. Plus, this can be quite useful for genres that are very featurings-prone, even though I can see some edge cases so maybe to use other specific ID3 tags is a better idea. On a small side note, can we avoid to use semicolons in the UI in general? They're just incredibly ugly, I'm not talking about the tagging-side, just the visualization, spaced forward slashes are way more organic on the eye. Just look at: Miles Davis; Sonny Rollins; Red Garland; Paul Chambers; Philly Joe Jones Miles Davis / Sonny Rollins / Red Garland / Paul Chambers / Philly Joe Jones That may seems a futile detail but since we're here to talk, just my two cents. Hope this will be implemented soon!
  19. Because ID3 tags are a way to store all types of album related-data, not necessarily only the ones needed to have a good-looking library, and since for me what a music player should do is to create an abstraction layer from what humans perceive as important in their music library and what's contained in their files, I don't see this request as that unreasonable (if I just want a raw display of my ID3 tags I can use a File Manager, right?). Plus: this is how Picard and MusicBrainz in general works with classical recordings (the first artist in the list is the most relevant one), and in a way it's more or less an open standard that everybody can agree with (Do you really want a list entry for every single combination of composer, singer, symphony, chorus, etc?)
  20. What about the idea to add the option to parse only the first artist in the list? I've seen this implemented in others players/scrobblers. This may seems unusual but if you listen to a lot of classical music you probably want a record to be under (e.g.) Ludwig von Beethoven , and not six duplicates of it under Margarete Bäumer, Heinz Sauerbaum, Manfred Hübner, Symphony Orchestra of the Mitteldeutsche Rundfunk, Chorus of the Mitteldeutsche Rundfunk, Gerhard Pflüger. This may be implemented on single album-level, but a general option in the settings would be appreciated too.
×
×
  • Create New...