jaxtherogue
-
Posts
53 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Downloads
Poweramp Knowledge Base
База знаний Poweramp
Poweramp知识库
Poweramp Equalizer Knowledge Base
База знаний Poweramp Equalizer
Store
Events
Ideas
Posts posted by jaxtherogue
-
-
JRiver took a look at all of my example files and found the below"
Quotewe save our tags with extra line breaks, which are technically valid but totally useless, and thats really the main difference here. Removing those and the tags start working for me in other tools. This will be fixed in a future build.
So, once the new build if JRMC is out I will test- thought I would share this is case it leads to any adjustment into how Poweramp deals with files with the extra line breaks.
-
3 hours ago, andrewilley said:
By the way, that 1Mb PNG image is a bit excessive if you are mainly using the OGG format to save you a few bytes of filesize per the same quality. You are also saving the files at 96kHz, which is also excessive if you are trying to save space (converting to 48kHz would be pretty-much unnoticeable, even with £1,200 ear buds, and would reduce the file sizes a lot).
All true. It's mostly laziness that the art size is unchanged and the bitrate is that high on my export. JRMC won't auto change the art size for me on conversion (and I want the orginal art in the flac files to be on the high end) and while the ogg encoder can be told to resample, it won't do so dynamically based on the source file. The vast majority of my flacs are 48khz and below so, when the occasional 96+ file slips in, I don't bother to correct it.
edited to add: after some digging I did find a way for JRMC to downsample to more reasonable 48/44 depending on the source sample rate. It doesn't do it in in the encoder, but I can do it by automatically applying a DSP before it encodes the file. I can the target downsample based on the sample of each source. I am reconverting now to see what the real world difference in the size is for the library i copy to my phone.
-
If it helps nearly all of my music is archived in FLAC. You can listen to transcodes to either ogg vorbis or opus and judge for yourself. IMO both vorbis and opus beat mp3. I don't have golden ears, but when I listen with iems (JHaudio jh16v2) MP3s fatigue me, opus and ogg vorbis less so. For car listening I can't say I hear any difference between the formats. If my next phone has more than 128GB of memory, then I'll likely just keep my files in flac.
my weird habits aside, I appreciate you looking into it.
-
Does any of this new info help point to a solution?
-
Also should have updated that I switched to OGG Vorbis hoping for different results but see the same thing, so this is not an OPUS thing. The above files are OGG.
-
here are the three files mentioned in the previous post. FYI, the JRiver Media Center team is also checking these files.
https://drive.google.com/drive/folders/12n9sSw6RlcgXR0ylhrHhlmM335Mr2tTd?usp=sharing -
After examining a number of files it appears that the "Picture Bits Per Pixel" tag is causing errors with reading the embedded artwork in the file. JRMC is writing to that tag. MP3Tag strips it out and also strips out the picture dimension tags. and the DBpoweramp converter writes the dimension tags but not the "Picture Bits Per Pixel" tag. Is it possible that this "Picture Bits Per Pixel" tag is causing an issue for Poweramp?
Here is the EXIF info:
File 1 (embedded art not showing in Poweramp):
Picture Type : Front Cover
Picture MIME Type : image/png
Picture Description :
Picture Width : 700
Picture Height : 700
Picture Bits Per Pixel : 32
Picture Indexed Colors : 0
Picture Length : 905796
Picture : (Binary data 905796 bytes, use -b option to extract)File 2 (working, tags resaved by mp3tag)
Picture Type : Front Cover
Picture MIME Type : image/png
Picture Description :
Picture Width : 0
Picture Height : 0
Picture Bits Per Pixel : 0
Picture Indexed Colors : 0
Picture Length : 905796
Picture : (Binary data 905796 bytes, use -b option to extract)File 3 (working, encoded with dbpoweramp)
Picture Type : Front Cover
Picture MIME Type : image/png
Picture Description : Cover artwork
Picture Width : 700
Picture Height : 700
Picture Bits Per Pixel : 0
Picture Indexed Colors : 0
Picture Length : 905796
Picture : (Binary data 905796 bytes, use -b option to extract) -
7 hours ago, MotleyG said:
These tests were posted in 2011/12, using sample rates of 64k and lower for the A/B testing. I would think that by today’s standards, most people are using much higher rates even for lossy formats like mp3 and AAC. Notably, there were little to no benefits once compression rates exceeded 64k, as evidenced in the results in both links.
if you hear a benefit in your experience, that is clearly your call. But this I would suggest Is subjective at best given these posted actual results. But more importantly, since the format has not gained widespread support from the audio community in the 10 years since it’s inception, it isn’t likely going to get much attention from the player app developers at this time.
The aduio merits of opus aside- just as a point of interest I have been using opus files with Poweramp for 2+ years and never had an issue until the last 2 weeks. And Jriver just keeps expanding its opus support. So adoption is slow, but growing in the tools I use the most. All that said, after some more testing I am pretty sure the issue is not with Android Beta or PA, so I am working with the Jriver people to see if something changed in how they are handling opus cover art tags. Thanks for everyone's input!
-
2 hours ago, andrewilley said:
I don't know, all I can say is that simply re-saving the tag data (making no other changes, sand without changing the actual audio data) using standard tag editing tools fixes the problem. @maxmp might be able to analyse your sample file further to see what is happening here.
I still question the use of the OPUS format for conversion of FLAC music files in the first place, as it is incapable of storing CD-quality recordings without changing them from 44.1kHz sampling to 48kHz, which cannot help the quality. The format is optimised for speech, not music. See https://en.wikipedia.org/wiki/Opus_(audio_format)
Andre
regarding opus. You should give it a listen- and numerous listening tests confirm that Opus is quite excellent for music. A couple posts I can recommend that consolidate a lot of info about opus in this regard, but really you will only know by giving it a try.
Auphonic Blog: Opus, the revolutionary open audio codec for podcasts and internet audio
Results of the public multiformat listening test (July 2014) (coresv.net)
-
3 hours ago, MotleyG said:
What format is mp3tag reporting that your files have? Sounds like although mp3tag can read the metadata, it may not be in a format friendly to other media players like Poweramp. Especially Ape tags, these are not well supported.
According to mp3tag it is using "Vorbis Comment". Just in case I was not clear this only just started happening in the last two weeks. Prior to this PA had no issue with seeing the art in my opus files. Trouble is, in those last 2 weeks I got updates from jriver, Poweramp, and the Android 12 beta..right now it is looking more like the jriver update might be the source of the issue, although the opus encoder it is using is the same external opus encoder I have always used. But who knows, Jriver MC can get complicated.
-
2 hours ago, andrewilley said:
Your file doesn't seem to contain very standard metadata, maybe Max could re-code around it? But in the meantime, you could re-save your metadata using a tag editor such as TagScanner or MP3Tag - I tried the former and the resulting file was fine in PA.
By the way, why are you converting to OPUS in the first place? I checked that FLAC track on Bandcamp, and their page says it is CD-quality - which would presumably mean 44.1kHz sampling. But that's not a frequency that OPUS supports, so any such files will get transcoded to 48kHz.
Andre
In what way is the metadata non-standard- I am trying to understand so I can share that info with Jriver in case it is their app that is doing something funky. I doubt I would be able to recognize oddly formated metadata myself.
As for Opus I am converting just to cram more music onto my daily carry phone. For home listening and on my dedicated portable music player I use flac.
-
For the new files the info/tags is showing there is no embedded art at all, though I know there is and have verified as much with a couple tag editing apps on my PC. I use Jriver MC to manage my library and export from flac to Opus for use on my phone. JRMC also sees the embedded artwork. I have attached an example file.
-
unfortunately that did not resolve the issue
-
Poweramp 906-910
Android 12 beta 3
Pixel 4Poweramp no longer seems to be able to read the embedded album art in any new opus files I sync to the device. For anything already on the device prior to the last week the album art is fine. No changes were made in how I generate the files (source is all FLAC). Files play with no issues. Tag editors on my PC (such as mp3tag) are able to see the embedded album art in the files.
-
quad dac support in lg v30/v30+
Poweramp no longer reading embedded album art
in Poweramp Bug Reports
Posted
Just to close the circle- the new build of JRMC does indeed solve this issue for my ogg vorbis and opus exports and seeing the embedded art in Poweramp. Thanks!