HydrogenAudio

What lossy  formats do you use on a *regular* basis?  :)

This is how 2016 ends
(https://s7.postimg.org/b8n56jkgr/codecs2016.png)

I put in my vote for MP3, since that is the format I encode to, for local storage.

The majority of my listening is through spotify, so I could also have chosen Ogg Vorbis, but the specific format doesn't really matter when you're streaming.

I voted AAC but i don't use it anymore since i got a new 256gb microsd & use flac now.

I voted AAC but I feel like there is a drumroll happening for Opus. Once a couple things get sorted out with the format I'm ready to make the jump. I have already noticed that it's more efficient than AAC at multichannel audio (did some fast ABX tests only for myself) and the threshold of transparency is at lower bit rates than AAC. I was a bit shocked because I expected AAC to be just slightly above Opus in the tests. I guess we need to consider multichannel ABX tests for formats that support it. Some tests that I've done after that incident showed me that results don't or may not importantly mirror the same results we have from Stereo tests. Also after that, something told me to do an efficiency test to lossless formats with similar results (size reduction and speeds don't reflect the same results as Stereo content tests).

Voted MP3 as that's what I encode to still, but I use AAC and MP3 in equal measure and stupid poll won't let me vote for multiple.

Since Hydrogenaud.io has a new engine a poll admits only one choice (and no multiple questions.)

All claims to administrators of forum.

Only accepting one option makes this poll nearly pointless, in my opinion. Why don't you try Google Forms, Surveymonkey, Typeform or similar?

In 2017
storage equipment is very cheap and high capacity
why not use 320k、V0 MP3 or high bits AAC replace others ?
I think format compatibility is important than quality...

I think format compatibility is important than quality...

I agree, though I don't see quality being an issue.  Of those fearful about quality, very few are aligned with reality; especially among those preaching high bitrates and/or non-mainstream formats.

why not use 320k、V0 MP3 or high bits AAC replace others ?

Because that's not how people see or take lossy codecs. For example I like to archive in lossless but when I use lossy I like to go the lowest as possible to be transparent or almost. I think MP3 V3 or AAC ~96/128 or Opus ~96/128 are more than enough .

I transcode everything to AAC...  I use a higher bitrate as I have a 160 GB iPod that can store weeks worth of music at that bitrate.  iTunes plus preset at 256 kb/s.  I tried an ABX to see if I could tell the difference from the original vs. the AAC file, and I had to guess almost every time.  Bliss.
JXL

I switched to wavpack lossy (+ correction for lossless archive). I agree compatibility is an important factor, but wavpack is playable on all the devices I use for playback (PC, phone, car(via  phone)), so the convenience of only having to maintain one music library is what is more important to me, especially now that I have less time to spend in front of my PC tinkering.

The size of the lossy part is rather large, but oh well. I don't need to have my whole library on my phone anyway.

Stlll on Musepack because AFAIK it's still the fastest decoding lossy codec on Rockbox. If it ain't broken, etc.

I voted Opus. I cherish freedom and quality, and Opus checks both boxes. Compatibility isn't a good argument. Freedom respecting formats will never gain wide adoption if those of us who care don't base our purchasing decisions with that in mind.

I use a variety of formats at Extreme and Insane bitrates where their relative quality is indistinguishable, encoded at different time periods, lately mostly Musepack SV7 and Ogg Vorbis, which have wide application support with full metadata. On PC all formats have almost equal usability. I use WavPack Lossy for source material of reduced quality, cassette tape, mini disc, transcodes from lossy codecs with editing, where lossless file sizes would seem excessive. I can recognize those files by the file extension since I do not use WV lossless at all.

The only format of the above I do not use is AAC, because I do not like the metadata system in the Apple container, which changes from one player version to another, sometimes exposing unreadable technical fields. Actually, I also do not use lossyWav either.

Opus ~128 kbps for me.

I used OGG exclusively for my dedicated music players before switching to MP3 since the music app I'm using on my mobile device currently doesn't support Album Artist tags for Vorbis. Could have re-encoded to AAC instead but at the time it was a bit of a 'screw it' decision (which is weird in hindsight given I spent quite a bit of time A/B'ing AAC vs FLAC a few years ago to find the lowest transparent bitrate to me). Not sure it makes much difference at 320kbps CBR though, apart from storage space.

So my vote would be split between OGG/MP3, since I still have an great number of previously transcoded OGG tracks as well.

I know the reaons why we don't have multiple choices but I still would have liked another option, in my case for WavPack Hybrid. For daily use it's Opus.

This hasn't changed for me in about eight years now, FLAC for archival/storage and AAC for playback.

I know the reaons why we don't have multiple choices but I still would have liked another option, in my case for WavPack Hybrid. For daily use it's Opus.

Could you please elaborate on why you went with WavPack Hybrid, but still use Opus as daily lossless instead of the lossy WavPack part? Why not go with WavPack lossless + Opus, then?

FLAC on my desktop, transcoded to Opus for my phone.  My players will support just about any format and they're all pretty much transparent at the bitrate I tend to use; I chose Opus just because I like FOSS.

FLAC on desktop for archivization purposes only. I almost always listen to music on my phone. 128kbps Opus for CD rips (and sometimes for some decent 320kbps MP3s) and 96kbps Opus for 128kbps MP3 transcodes (my library was full of MP3, but I'm transcoding them to Opus to shrink them further).

Could you please elaborate on why you went with WavPack Hybrid, but still use Opus as daily lossless instead of the lossy WavPack part? Why not go with WavPack lossless + Opus, then?

Certainly. WavPack Hybrid is used for archiving, Opus for my Smartphone.

Quote from: ChronoSphere on 2017-05-11 21:19:35

Could you please elaborate on why you went with WavPack Hybrid, but still use Opus as daily lossless instead of the lossy WavPack part? Why not go with WavPack lossless + Opus, then?

Certainly. WavPack Hybrid is used for archiving, Opus for my Smartphone.

The part I don't understand is why you are using hybrid (lossy + correction file). If you are never using the lossy part of your archive, you might as well archive in wavpack lossless, and save several Mb per track at same compression settings...

Since Hydrogenaud.io has a new engine a poll admits only one choice (and no multiple questions.)

Change the question, then. Comparing the results with previous years is anyway broken and useless, so there is no point in keeping a question that even pretends they will be comparable.

Following KozmoNaut, I choose MP3 because that is the format I encode to. And it is also the lossy format I listen to most when it comes to files as opposed to streams. I too think streams are a different thing, and since now I can only answer one codec, I go for the one I use for files without thinking of how much I listen to Spotify.

I regularly listen to files:
- those MP3s
- other lossy files in whatever codec they may have arrived (MP3 is more than 99 percent; then AAC and WMA and AC3 should be mentioned for a "regular basis" question)
I regularly listen to streams:
- Spotify (Vorbis)
- checking out bands and releases at Bandcamp and Soundcloud (MP3)
- inevitably, streaming video in whatever their formats are at the moment ... YouTube change every now and then, and I have no idea what format my newspaper sends to my Android browser

I chose Opus just because I like FOSS.

Wouldn't LAME-encoded MP3 qualify now?

it has a dirty past   :D

Quote from: Heliologue on 2017-05-11 21:51:07

I chose Opus just because I like FOSS.

Wouldn't LAME-encoded MP3 qualify now?

Now, sure.  Although Opus has the added benefit of being a somewhat more sophisticated codec.

Practically speaking, with perhaps the exception of AAC-via-FAAC, any lossy codec is going to be just fine on a phone with cheap headphones (Kamedo2's 2014 test (http://listening-test.coresv.net/results.htm)), so one's choice in this domain is more or less arbitrary.  I'm a Xiph fan, so affiliation drove my choice more than any kind of technical benefits of the codec, per se.

I choose .OPUS.  Fine drum symbols and classical string instruments 'seem' to make it to the final product.

"Feel the .opus force flow through your headphones."

The part I don't understand is why you are using hybrid (lossy + correction file). If you are never using the lossy part of your archive, you might as well archive in wavpack lossless, and save several Mb per track at same compression settings...

Well, does the expression "hybrid" in connection with WavPack always mandate the use of a correction file? To my knowledge, WavPack Hybrid also describes lossy compression without correction file. Which is what I use. And the way WavPack Hybrid compresses does not forbid possible transcoding with other codecs :)

it has a dirty past   :D

I used to be a cheap girl, but now I am free!

Opus (default ~96kbit/s) on my Android device, with GoneMad! Player. Sound reasonable in my car and with my headphones, and makes anything fit on my 64GB SD-card.

Anything that goes to google play or thumb drive on the car system is mp3 because that's what they like.
Stored directly on phone are generally Opus.
Most of what's in the music folder on the PC is still vorbis, but haven't been encoding in that for a few years.

My vote goes to opus cause is the most sophisticated lossy format nowadays. I encode at 155 kbps and play on my android phone with Aimp player conected to my HiFi amplifier.



P.D.: Sorry for my english.

Quote from: ChronoSphere on 2017-05-13 10:29:07

The part I don't understand is why you are using hybrid (lossy + correction file). If you are never using the lossy part of your archive, you might as well archive in wavpack lossless, and save several Mb per track at same compression settings...

Well, does the expression "hybrid" in connection with WavPack always mandate the use of a correction file? To my knowledge, WavPack Hybrid also describes lossy compression without correction file. Which is what I use. And the way WavPack Hybrid compresses does not forbid possible transcoding with other codecs :)

Well, to me, "hybrid" implies a hybrid between two or more distinctive features. In this case, lossy and lossless, which would mean that yes, it mandates the use of a correction file. I don't know how others see it though.

Basically, this is how I classify the WavPack encodes:

WavPack lossless = lossless only
WavPack lossy = lossy only
WavPack hybrid = lossy + correction file

Thus my confusion about your choice - or rather, definition.

AAC for compatibility reasons (and sometimes space on DAP), otherwise WavPack lossy.

Basically, this is how I classify the WavPack encodes:

Code: [Select]

WavPack lossless = lossless only
WavPack lossy = lossy only
WavPack hybrid = lossy + correction file

Thus my confusion about your choice - or rather, definition.

I understand. I called it 'WavPack lossy' for an article on my blog and explained the correct designation within (). But that article was for people who don't know anything about lossy codecs so I used it to differentiate it from the lossless mode. Officially, WavPack Hybrid seems to be used to describe both modes and I've never seen the term 'lossy'. We could of course ask David Bryant :) But I also don't want to make a fuss about it.

I use Opus at about 96kbps, this way I can fit quite a lot of songs on a 32GB mSD card. They play on a rockboxed ClipZip, on foobar2000, on some linux players, on my Android phone, with bluetooth for the car. And lacking any of those, for that moment when: -Hey man! check this song! -Ok, Wait... How do I play this? -Just drag and drop to a firefox tab XD

I don't encode anything to lossy any more. Having said that, I voted mp3 because a good chunk of my collection consists of it.

I understand. I called it 'WavPack lossy' for an article on my blog and explained the correct designation within (). But that article was for people who don't know anything about lossy codecs so I used it to differentiate it from the lossless mode. Officially, WavPack Hybrid seems to be used to describe both modes and I've never seen the term 'lossy'. We could of course ask David Bryant :) But I also don't want to make a fuss about it.

:)

In the dim past there was a pure WavPack lossy mode (Shorten had such a mode also). At high enough bitrates they worked very well.

When the hybrid mode was developed, I decided to call the new mode “hybrid” even when there was no correction file present because, well, there could be a correction file present, and I wanted to differentiate it from the old lossy mode (which was not nearly as good).

So now I currently report them as being the "hybrid lossless" and "hybrid lossy" modes. But certainly calling the hybrid mode without a correction file just “lossy” would be correct too (and unambiguous).

:)

In the dim past there was a pure WavPack lossy mode (Shorten had such a mode also). At high enough bitrates they worked very well.

When the hybrid mode was developed, I decided to call the new mode “hybrid” even when there was no correction file present because, well, there could be a correction file present, and I wanted to differentiate it from the old lossy mode (which was not nearly as good).

So now I currently report them as being the "hybrid lossless" and "hybrid lossy" modes. But certainly calling the hybrid mode without a correction file just “lossy” would be correct too (and unambiguous).

That clears it up!

Thank you :)

Does "using" also count as using Youtube and their set of encoding formats? I.e. listening to music on Youtube and watch videos?

Does "using" also count as using Youtube and their set of encoding formats? I.e. listening to music on Youtube and watch videos?

That would be technically correctly (the best kind of correct!), but I have a feeling that the poll is meant to understand the intentionality of your personal codec choice.  Certainly, streaming services have their own reasons, which may be biased toward efficiency over quality;  it would cost me nothing but additional storage space to use FLAC on my phone, but Google would be out of their minds to, e.g., stream lossless audio from Youtube.

How I Learned to Stop Worrying and Love MP3 back again!

'cause:
- my ears are not that young anymore;
- my patience with trying every new bit of  'promising' new coded has probably run out by now;
- I can't hear anything discernibly wrong with MP3 - at all!*

Edit: Oh yeah: COMPATIBILITY!
Later: even more so when driving or listening to music whilst actually getting some work done.
I' guess I've never been the sort of purist who sits down in an armchair (rightly posioned in the room) with the sole intent of listening to music hours on end.

How I Learned to Stop Worrying and Love MP3 back again!

'cause:
- my ears are not that young anymore;
- my patience with trying every new bit of  'promising' new coded has probably ran out by now;
- I can't hear anything discernibly wrong with MP3 - at all!

Edit: Oh yeah: COMPATIBILITY!

Yeeaaah, get a copy of Plugger MP3 encoder and convert your favorite FLAC to 112kbps MP3 with it...

Seriously though, MP3 isn't that bad at all, when using with LAME, and in most circumstances. my car audio system can only decode WAV, MP3 and I think WMA, although I'm not sure. So MP3s it is for that use case.

Seriously though, MP3 isn't that bad at all, when using with LAME, [...]

You don't say!

Yeeaaah, get a copy of Plugger MP3 encoder and convert your favorite FLAC to 112kbps MP3 with it...

I honestly hope that poor attempt at a joke was not at my expense.

From my side, I encode my FLAC collection to Ogg Vorbis, especially since this is the format which passed a gapless playback test I did, best.

I compared LAME-encoded MP3, Apple AAC and Vorbis (using aotuv) with a pair of tracks with seamless transition. The test has been done with Poweramp 2, and I realized short glitches between the tracks with both MP3 and AAC. Ogg Vorbis was the only format where the transition was really clean and seamless.

I actually don't know if this is an issue of Lame / MP3 / AAC, or more an issue of Poweramp, but since this is the player I use for portable listening, vorbis was the codec of my choice to use :)

I voted mp3.  I started with mp3, then went to flac, and then realized I can't hear a difference with my audio gear.  Over the past few weeks I started converting my flac to AAC256 due to the smaller file size and once again I can't hear a difference so AAC makes more sense.  I know there are other formats that offer even smaller file size, but not all of them are supported on my portable DAPs.

I voted for AAC. i recently re-encoded my entire collection (pretty much) to AAC @ 128kbps from my FLAC files. i used to have MP3 (LAME v2 (190kbps average)) but i figured, while those are good quality, they are not that efficient with the storage space on my 16GB MicroSDHC card which i got in my Sansa e250 v1 running Rockbox. it seems those looking for a more efficient use of storage space, AAC is a better option than MP3 nowadays as while MP3 is always a safe choice when it comes to wide compatibility i figure there are probably not that many older devices out there that cannot also play AAC at this point in time. so in a way MP3 is somewhat obsolete especially if your device can play AAC or Opus etc.

AAC-LC encoded with Foobar2000 (i also have Foobar2000 Encoder Pack installed to) using Apple AAC encoder @ q63 (128kbps) TVBR mode is what i used. this sounds like a safe setting for quality/file size/compatibility nowadays.

my alternate choice... Opus @ 64kbps (maybe 80kbps(or 96kbps/128kbps TOPS)). that seems to be the minimum i would recommend especially for music your not too concerned with having top quality sound but still sounds respectable. but i have a feeling that 80kbps recommendation from others here is a solid choice to for those looking for a great balance of sound quality/storage space(but lean a bit towards storage space). but 80kbps would give a 20% increase in file size over 64kbps. but i guess for those who are using Opus as their primary lossy format i would also likely go with 80kbps minimum (gives a bit of a buffer there over the 64kbps setting which i feel sounds pretty good) and would even consider 96kbps or 128kbps settings. i figure with modern lossy encoders it's not worth using beyond 128kbps as beyond that point i feel they start to lose a lot of their efficiency and starts to defeat the purpose of using a lossy encoder in the first place which is to save storage space.

but about that Opus stuff... just on my PC (which has Klipsch Pro-Media speakers(i would say these are better than your average computer speakers. i have had them since the early 2000's)) using Foobar2000 doing a quick ABX test, while i never actually completed the ABX test in what i am about to say, i have found that going from 32kbps to 48kbps to 64kbps you can notice it just from playing the Sample A and Sample B like swapping between the two it's not that hard to tell the Opus file from the FLAC file but once i hit 64kbps my confidence in picking the FLAC over the Opus file, without actually completing the ABX test, disappears which is why i figure 64kbps is the minimum i would recommend for Opus music if your trying to get maximum storage space without quality dropping off TOO much(although i will say even 32kbps/48kbps settings are respectable considering the really low bit rates). but i have a feeling that 80kbps setting is more of a safe buffer there as i seem to be similar to some other users comments i have read recently. but just given what i said i feel once you hit 64kbps all of the more easier to detect sound flaws are largely gone to the point, when just listening without focusing too hard on trying to find flaws etc, i feel 64kbps is easily decent enough and gives nearly double the storage space of Apple AAC @ TVBR q63 (128kbps).

that's why i settled on Apple AAC @ q63 (128kbps) + Opus @ 64kbps combo for my general music collection for playing back on my Sansa e250 v1 with the 16GB MicroSDHC card as it helps efficient storage space/sound quality combo as after i switched to that from MP3 i basically got my entire collection, and then some, and still have more than 6GB left where as before i only had about 1.5GB free. because even if not much hardware supports Opus, i always have the 128kbps AAC's to fall back on and that bit rate is high enough to where it's a safe setting for quality (and keeping file size efficient). like with that AAC stuff... i won't have to worry about having to re-encode to another format at this point in time.

just some thoughts ;)

p.s. to encode Apple AAC in Foobar2000... i simply extract the 'AppleApplicationSupport.msi' out of the newest iTunes installer using 7-zip and then install that and then Foobar2000 has no issues encoding Apple AAC files once you have the Foobar2000 Encoder Pack installed (that encoder pack also allows for Opus v1.2 encoding to). all are free.

SIDE NOTE: i assume Opus takes more CPU to decode than Apple AAC? ; because while both Apple AAC and Opus files play fine on my Sansa e250 v1 player i do notice when navigating the menu's in Rockbox while a Opus file is playing get a bit sluggish which does not happen when playing Apple AAC (AAC-LC) files as the AAC files everything works as expected. that sluggish effect remains pretty much the same whether i tried Opus @ 32kbps or 128kbps but the music playback seems to work fine as i don't hear any stutters etc.

p.s. to encode Apple AAC in Foobar2000... i simply extract the 'AppleApplicationSupport.msi' out of the newest iTunes installer using 7-zip and then install that and then Foobar2000 has no issues encoding Apple AAC files once you have the Foobar2000 Encoder Pack installed.

Unneeded confusion, you don't need to install anything from Apple, I am strongly against installing anything in general, I use most I can in portable mode. You can use the iTunes libraries in portable mode too with "makeportable" from nu774, download here: https://sites.google.com/site/qaacpage/cabinet

For the rest, there are recommended settings for every codec on the hydrogenaudio wiki, they say approximately when a codec is close to transparency as well. I didn't mean to sound rude by any means, thanks for the info and keep testing. I am able to hear distortion in the bass with my iPhone in speaker mode at 64 for Opus but I can't distinguish at 96, didn't try 80 but I'll do more testing that's why I didn't "report" anything yet.

@eahm ; I got that 'makeportable' batch file to work this time simply because i noticed it created a folder called 'QTfiles' inside of the working TEMP folder i made (like i put batch file and iTunesSetup.exe into that TEMP folder) and then i loaded up the command prompt in administrator mode (i don't know if that part is needed or not but i did that to ensure it functioned properly) and then went to the D:\TEMP\ folder and then ran the 'makeportable' (without the ') and hit enter and i seen it do something real quick in the dos window but at that point i figured it was all automatic and tried to encode a Apple AAC file like usual in Foobar2000 but it failed and then i went and checked the D:\TEMP\ folder and noticed it made a 'QTfiles' folder at which point i took a guess and copied and pasted the entire 'QTfiles' folder to Foobar2000's 'encoders' folder and then tried encoding a Apple AAC file like usual and it worked! ;)

but i wonder if i can simply just put those two files into a folder and then right click the 'makeportable.bat' file and select 'run as administrator' will do the trick (or can i just click the makeportable without the admin mode?) or do i have to manually run things from a command prompt like i did. i guess i could test but ill see what you think first.

but that does cut down on file size a bit as it's "37.7 MB (39,543,904 bytes)" (although if i compress the 'QTfiles' folder with 7-zip that shrinks it down to only "9.23 MB (9,684,216 bytes)" ;) ) vs the .msi file (i.e. 43.8 MB (45,940,736 bytes)) and i don't need to have any from Apple installed as this seems more of a proper way to use these things. but it does not come with any basic instructions as i could easily see how some people would not know what to do even if they got the basic 'iTunesSetup.exe' and 'makeportable.bat' into the same folder and then executed the .bat file as i imagine running it straight up without actually going to a command prompt will probably flash the window quickly and one will wonder what the hell happened.

but once you confirm what i was asking above ill edit my couple of posts suggesting people use the AppleApplicationSupport.msi and guide then to that makeportable.bat instead. but even though you and i prefer the way you just recommended to me i could see why the average person would rather do things the way i initially described with the .msi file because it's a bit quicker/simpler to get things up and running as a bit less computer knowledge is needed. because i am just hoping to tell someone to create a TEMP folder and put those two files (i.e. iTunesSetup.exe (the 32bit one) and makeportable.bat) into the TEMP folder and then simply execute the .bat file and then tell them to copy the created 'QTfiles' folder to Foobar2000's installation folder under the 'encoders' folder and then they are golden ;)

p.s. the two Winamp FhG files compressed with 7-zip are only 420 KB (430,781 bytes) in size. but it seems this encoder is only worth using if someone wants files around 32-48kbps etc and being more of the AAC-HE standard which is more CPU intensive etc.

I am able to hear distortion in the bass with my iPhone in speaker mode at 64 for Opus but I can't distinguish at 96, didn't try 80 but I'll do more testing that's why I didn't "report" anything yet.

Okay, thanks for the info.

it's cool, as i know what i said some people will have differing opinions and all as like i said i was just doing a pretty quick test and found @ 64kbps things were not obviously off at that point without spending much time listening to sounds more focused etc. so it's possible i could notice some artifacts if i put more effort into it but i think 64kbps is up to a standard that the overall sound is not obviously weak(especially given it's not far from 96kbps which people seem to think positively of), even though i would have no doubts that some users here would have no problem picking up on it. but if i recall correctly i think i read that someone who's trained to spot artifacts can pick up on them more easily than people like me who likely can't etc(?). because i guess when i listen to music in general i am mainly focused more around the singers voice than anything else as long as there is no obvious weird fluctuations in the overall sound outside of that it will probably be harder for me to notice(i know some people can give some pretty technical terms to specifically point out what it is they are hearing but i don't know all of that technical terms on what i am hearing other than something is off or not etc).

but are those iPhone speakers any good? ; it seems like those would be harder to notice unless those speakers on there are better than i think they are as i never played around with a iPhone, pretty much. so ill just have to take your word for i.

You need 7-Zip to run makeportable, you can get that one portable as well (https://portableapps.com/apps/utilities/7-zip_portable), just copy the 7z.exe where makeportable.bat is.

@eahm

You need 7-Zip to run makeportable, you can get that one portable as well (https://portableapps.com/apps/utilities/7-zip_portable), just copy the 7z.exe where makeportable.bat is.

I assume you meant to link to this (as your link don't work because you got the ")," which got included as part of the link)... https://portableapps.com/apps/utilities/7-zip_portable ; but the good news is, i already got 7-zip installed straight up from the official 7-zip website.... http://7-zip.org/ ; that must have allowed the .bat file to work for me. but i would have to mention that to people that in order for the makeportable.bat to work they need 7-zip installed on their system (or put that .exe in the same folder as the makeportable.bat like you said). but i guess that complicates things a bit more for some computer challenged people which makes it a bit easier for me to just tell people to install things with the .msi, but then again i needed 7-zip installed to extract that .msi file out of the iTunesSetup.exe in the first place.

hell, it's just going to be much easier for me to make a .zip file and upload it somewhere and then simply tell people to download it and then extract it to "C:\Program Files (x86)\foobar2000\encoders" (without the ") as that would be easier than explaining things to people ;) ; or is linking to something like that not allowed here?

but do you know if running that .bat file in 'Run as administrator' mode is required or not? (i could play around with things myself but i just wondered if you knew straight up so i could dodge the testing)

We are OT but no, no need to copy the .exe if you have it installed and no need to run as administrator, only the .exe of iTunes and makeportable.cmd (.cmd sorry not .bat) in the same folder and it will create QTFiles and QTFiles64 if you downloaded the 64bit version.

We are OT but no, no need to copy the .exe if you have it installed and no need to run as administrator, only the .exe of iTunes and makeportable.cmd (.cmd sorry not .bat) in the same folder and it will create QTFiles and QTFiles64 if you downloaded the 64bit version.

That should clear things up. but one last question... it's not possible to use the 64bit version of Apple AAC encoders with Foobar2000, since Foobar2000 needs 32bit stuff since it's 32bit itself, correct?

p.s. my bad with the .bat thing.

You can of course, the CLI runs indipentently and foobar2000 looks for both versions when you send the convert command.

You can of course, the CLI runs indipentently and foobar2000 looks for both versions when you send the convert command.

It errors when i try using 64bit Apple AAC encoder but works with 32bit. there must be something that makes it conflict which i assume has something to do with Foobar2000 being 32bit and that Apple AAC from the 64bit iTunes download with the QTfiles64 files being 64bit. looks like ill have to stick with the 32bit ones.

i was just curious if the 64bit sqeezed a little extra encoding performance (i.e. shorter encoding times) vs the 32bit version is all.

Quote from: eahm on 2017-10-15 11:27:08

You can of course, the CLI runs indipentently and foobar2000 looks for both versions when you send the convert command.

It errors when i try using 64bit Apple AAC encoder but works with 32bit. there must be something that makes it conflict which i assume has something to do with Foobar2000 being 32bit and that Apple AAC from the 64bit iTunes download with the QTfiles64 files being 64bit. looks like ill have to stick with the 32bit ones.

i was just curious if the 64bit sqeezed a little extra encoding performance (i.e. shorter encoding times) vs the 32bit version is all.

I am going to PM you a package you should test and analyze to see how the folder and encoders should be put inside the foobar2000's encoders folder.

I voted MP3 as I do still use them probably more than anything else at the moment lossy wise.

I also use AAC (M4A) a lot as a certain Radio station's audio is transmitted in 320kbps aac.

Given the choice I'd use OPUS though and have used it on some portable audio devices. Rockbox didn't seem to too happy with them though, which is a bit annoying.

@jaybeee

Rockbox didn't seem to too happy with them though, which is a bit annoying.

Rockbox v3.14 (newest official release which is from May 1st 2017) works fine with my Opus files except i think there is a bit of a CPU issue though on my Sansa e250 v1 as while the audio plays fine, when navigating the menus during playback of a Opus file the menu's are a bit sluggish as things are not quick to respond like they normally are when playing a MP3/AAC-LC file etc.

if your using a older build of Rockbox i would upgrade to at least v3.14

Not unexpected, since Opus is a bit of a CPU hog. Still:

(https://f.losno.co/fooSPEC_iPhone_8_Plus_sized.png)

It can't be too bad, unless I'm just holding a portable supercomputer here. Maybe most ARM devices that are sub-$150 kind of suck by design?

Could you please tell me what app that one is, @kode54 ?

Not unexpected, since Opus is a bit of a CPU hog. Still:

It can't be too bad, unless I'm just holding a portable supercomputer here. Maybe most ARM devices that are sub-$150 kind of suck by design?

If you mean the e200v1, it's an 11 year old player with a CPU core launched in the year 2000, so processing time is a bit tight.  That and I never got around to optimizing opus much for the obsolete arm cores.

Still, opus isn't slow. It really does decode on almost 20 year old embedded CPUs meant for mp3 (unlike aac-he). With more optimization, it'd probably be pretty close to mp3 or AAC-lc.

Maybe most ARM devices that are sub-$150 kind of suck by design?

There is a variety of smartphones (~100-120$, Moto -E/-C series) which have an efficient ARM chips those are capable to decode Opus and even Wavpack (highest preset) with 50-60 hours of battery life.

The thing is that Sansa chips are obsolete as hell. People can't pretend to use new formats on such awfully old devices.

Could you please tell me what app that one is, @kode54 ?

It is foobar2000 Mobile, the public App Store version, and this audio set is referred to as fooSPEC 2013 (https://f.losno.co/fooSPEC2013_files.7z). I am mirroring the file set just to reduce the bandwidth drain a bit, and also removed the bundled old release of Windows foobar2000, from when the benchmark was designed to test the speeds of various FFmpeg based codecs against the older player, which predated the inclusion of the mini FFmpeg.

Actually, 2013 only included a then-stable release. 2012 included the FFmpeg vs original comparison. 2012 also lacked the TAK file that I later added, which Mobile now supports, thanks to FFmpeg's reverse engineering efforts.

More arm benchmarks:

https://www.rockbox.org/wiki/CodecPerformanceComparison

Quote from: kode54 on 2017-10-16 01:37:42

Maybe most ARM devices that are sub-$150 kind of suck by design?

There is a variety of smartphones (~100-120$, Moto -E/-C series) which have an efficient ARM chips those are capable to decode Opus and even Wavpack (highest preset) with 50-60 hours of battery life.

The thing is that Sansa chips are obsolete as hell. People can't pretend to use new formats on such awfully old devices.

That's true and all but personally i don't want to use a 'phone' for playing music. i prefer using using a device actually made for music. plus, the Sansa e250 is nice and compact so it's easier to carry around and has expandable memory via MicroSD and a user replaceable battery which are ultimately why it's still worth using (i especially like Rockbox on it which is how things should work where you can directly access files/folders like you can in Windows Explorer etc) as if i only had the 2GB built in memory and that's it, it would be much more limited but since it supports MicroSD chips, it can hold a lot more music (basically my entire collection) and with using Opus occasionally it can fit even more onto it even though i suspect battery runtime might take a hit as i have not tested it in comparison to AAC-LC yet. but years ago i think it was 20 hours or so (at least 15+) battery runtime with MP3 on the e250 v1.

so unless something is quite a bit more difficult to decode than MP3, then it should play even on old hardware like the e250. i have had my e250 for 9+ years now.

p.s. i have a MicroSDHC 16GB chip in the e250 v1 and i realize i could always get a 32GB-64GB card as they are cheap enough(i.e. $15-25), and have been for a while now, but i just try to make the most of my 16GB card which as long as i use 128kbps Apple AAC i can fit my entire collection on that 16GB MicroSD with a fair amount of space left over and if i ever start to run a little low on space i could always swap a portion of it out to Opus 64kbps since i ripped all of my FLAC to 128kbs AAC/64kbps Opus. but if i ever do get a 32GB or higher card for the e250 at that point it's probably not worth using Opus at all, given the slight issues it has(sluggish menu's on Rockbox during playback and i assume drinks noticeably more juice from the battery), and i could exclusively use 128kbps AAC-LC (Apple q63 TVBR).

@jaybeee

Quote

Rockbox didn't seem to too happy with them though, which is a bit annoying.

Rockbox v3.14 (newest official release which is from May 1st 2017) works fine with my Opus files except i think there is a bit of a CPU issue though on my Sansa e250 v1 as while the audio plays fine, when navigating the menus during playback of a Opus file the menu's are a bit sluggish as things are not quick to respond like they normally are when playing a MP3/AAC-LC file etc.

if your using a older build of Rockbox i would upgrade to at least v3.14

I'm using the latest stable build. I sort of reported it here (https://hydrogenaud.io/index.php/topic,114021.msg940173.html#msg940173).

@jaybeee

after reading your link...

At least Opus works unlike HE-AAC (HE-AAC uses a lot more CPU cycles (not to be mistaken with the typical AAC-LC which works fine)) which will make your player unusable and you pretty much have to hold down the power button to turn it off. then power it back up and use other files like normal. i have tried Opus between 32-128kbps and it's pretty much the same in that it's useable but menu's are laggy. but how's your battery life on your e200 series with those Opus files, as while i never thoroughly tested it yet, i am going to assume there will be a noticeable hit to battery runtime. so assuming that's true, the laggy menu thing and potential solid battery runtime drop off makes Opus less appealing(even though it's a good audio format).

but i assume you got a e200 series v1 like i do? ; my guess is the v2 models will handle Opus fine due to a faster CPU as i think the v1's are pretty much 80Mhz but the v2's are 250Mhz.

basically with what we have, in my opinion, Apple AAC @ 128kbps (q63 TVBR) is your best all around bet for a safe sound quality setting while maintaining a efficient file size (like the sweet spot of quality/file size). that's why i recently converted all of my FLAC files to Apple AAC @ q63 (128kbps) TVBR mode (i was using LAME v2 (190kbps average)). by default Foobar2000 + Encoder Pack won't allow you to encode Apple AAC though even though it does include the qaac.exe file with that Encoder Pack (but you still need the actual Apple AAC files for that qaac.exe to work). if you want to use Apple AAC let me know as i can send you a file (in .7z format and is only 9.23 MB (9,684,216 bytes). basically it has a 'QTfiles' folder there which you simply extract to the Foobar2000 'encoders' folder and that's it, it will work) which will make it nice and simple to use the newest Apple AAC encoding in Foobar2000 as i extracted the Apple AAC stuff from iTunes v12.7 which is currently the newest one available. also, i am assuming you already have the latest Foobar2000 Encoder Pack installed. from what i hear IgorC say(which i believe was from a post earlier this year), when it comes to AAC format Apple AAC is THE best encoder in the 96kbps+ range.

...

thanks for the good info.

yeah it's a v1 e200 series (e270). as you say, must be the underpowered cpu causing the issues.

I've got the Apple AAC encoder setup in foobar and works ok (just tested actually). I'll probably end up using that at ~128kbps for my portable music coming from a lossless source.

Now using opus on a clip zip with no issues. Rockbox 3.14. Grateful to all.

That's true and all but personally i don't want to use a 'phone' for playing music.

I understand.

...and i could exclusively use 128kbps AAC-LC (Apple q63 TVBR).

You can't go wrong with Apple  LC-AAC encoder for 96 kbps and higher.
It was on top of all LC-AAC encoders in every public and personal test here in HydrogenAudio. All claims about superiority of any other LC-AAC encoder is simply not true ( always speaking of  96 kbps and higher)

Now using opus on a clip zip with no issues. Rockbox 3.14. Grateful to all.

I think that pretty much confirms what i suspected as i think you got a noticeably faster CPU (i think it's around 240Mhz but i can't seem to find anything definitive looking around on Rockbox website) than what our e200 series v1 players do which appears to be only 80Mhz.

with that said, i would not be surprised to see Opus use noticeably more battery than AAC-LC does on your device even though Opus functions well for you and there is apparently no laggy menu's while playing Opus encoded music. but i guess as long as the battery runtime does not drop off too much then you ain't got much to lose by using Opus over AAC-LC, especially if you don't care about the whole wide compatibility aspect of which AAC-LC will always beat everything, outside of MP3 of course. but i figure at this point in time it's not likely many devices that work with MP3 but don't work with AAC-LC are still in use anyways.

but i guess when it comes to the whole Opus vs AAC-LC (Apple AAC basically)... i suspect the trade off boils down to less battery life for probably a little better sound at the lower bit rates (when choosing Opus over AAC-LC). but i am not sure how Opus compares to AAC-LC once you get into the 128kbps+ range. but i figure even if Opus wins, it's got to be very little difference to most people in the real world as i would imagine even those with the golden ears etc who can detect artifacts at the 128kbps+ ranges it's probably something they got to be really focused on(?) and when just enjoying their music it would be negligible difference(?). that's basically why i feel Apple AAC @ 128kbps (q63 TVBR) is a safe setting (considering the public ABX test link below @ 96kbps from late-2014 that i linked to below) and is a nice efficient use of the encoder to as your not using excessive bit rates to clean up tiny things.

but as far as the 96kbps range... taking a quick look on these forums i found a public listening test from late-2014 that shows Opus was #1 with Apple AAC being #2 and that was before the Opus v1.2 release earlier this year which seems to further refine the sound quality of the encoder even though, from what i have read, most of the Opus v1.2 improvements are at the really low bit rates (say 32-48kbps or so, maybe 64kbps-ish a bit etc) which i would not be surprised if it squeezed a little more out of it. but like mentioned... with modern encoders like Apple AAC or Opus in the 96kbps+ range they are quite strong to where they simply cannot sound bad, even amongst those with the golden ears. so while these modern encoders are solid, to bad they were not this way say 10 years ago when storage space was not cheap etc as back in those days really low bit rates would have been more appealing as even being able to use 128kbps, like we can today (and for at least most of this decade), would have been nice as, if i recall correctly, using higher bit rates back in those days were somewhat required to get consistently good sound basically.

hell, just last night i was trying to do a ABX test on a random song i had with Opus @ 64kbps (in comparison to the FLAC obviously) and when i started the test i was confident i was hearing a difference for the first 4-5 choices (i was attempting to do 12 rounds in the ABX test) as i made my picks fairly quickly but after that i started losing confidence again (as i was no longer confident i was hearing enough of a difference to make a choice that i was confident in making) and stopped the test. but even assuming someone gives me the benefit of the doubt (in that i was hearing a difference), during the times i was confident i was making the correct choice, the sound was not that much different in that if i was not hearing the Opus @ 64kbps file in comparison to the FLAC file i doubt i could notice any differences when listening to the song straight up as the overall sound seemed consistent but there was something you could notice (i don't know how to describe it as i don't know the technical terms), like something in the overall sound altered just a little to be able to slightly detect it. but this is why i suspect, to play it a bit safer, if i had Opus @ 80kbps i would not be surprised if i could not ABX that, at all. so if that's true, then i would be very similar to some users around here who feel Opus @ 80kbps is a fairly safe setting because even if we could notice it at that point, it would likely be in that major focusing level of concentration etc which when your at that point, or even close, it's pretty safe to say the overall sound is pretty stable/good and likely will be on a wide range of music for us.

p.s. here is the 96kbps test i was referring to above... https://hydrogenaud.io/index.php/topic,106354.msg874674.html#msg874674 ; side note: you notice MP3 seems competitive there (but still a bit worse) but it's also using noticeably higher bit rates. so it's sorta cheating to stay competitive. hence, Opus/AAC-LC are just better as they use noticeably less bit rates to achieve similar sound quality.

I get a rippling sound once in a while when playing .opus music @64kbps with my Galaxy Note 4 in speaker mode. That's why I switched back to AAC - HE. The 64kbps in AAC HE (Apple) is perfect for mobile devices who wants to save more storage space, now I'm testing HE V2 to see if there's any improvement.

Only accepting one option makes this poll nearly pointless, in my opinion.

Agree. I use Opus on my phone, Lossywav on Desktop - which one should I choose for the poll? Chose lossywav because of its underdog position in 2016 -- hopefully that highlights the problem.

C.

Opus - in Desktop Linux distributions it always "just works" and now that foobar2000 works well on Android I don't need AAC anymore.

I Was Voted AAC or HE-AAC?

So, what do lossy compression audio there: is a MP3!

@novandroresonate2018 take it from another equally non-native English speaker:

You don't have to speak like Shakespeare in order to be understood over here, but man, you do have to brush up your English so that people can actually have a grasp of what you're trying to say!

Either that or, as it's been already advised, make proper use of Google Translate.

Or else you risk sounding like this guy:

(http://www.onpostmodernism.com/images/movies/borat.jpg)