IPB

Welcome Guest ( Log In | Register )

28 Pages V  « < 7 8 9 10 11 > »   
Reply to this topicStart new topic
QAAC: discussion, questions, feature requests, etc., [originally a thread for a feature request]
Anakunda
post Aug 14 2012, 21:24
Post #201





Group: Members
Posts: 450
Joined: 24-November 08
Member No.: 63072



QUOTE (jetpower @ Aug 14 2012, 22:15) *
AAC has less holes in high freq, also are you a bat?


No not a bat tongue.gif does "less holes in high freq" mean a worse encode quality? I think the hard cutoff at ~19.5kHz by AAC is no good but not sure about that.
I'm curious if iTunes does their encodes using the same QuickTime library or something else. Looked at iTunes original track which otherwise was a noticeably higher bitrate but there wasnot such a hard cutoff. Finally I'm not too impressed by the spectral of this TVBR.
Go to the top of the page
+Quote Post
jetpower
post Aug 14 2012, 21:36
Post #202





Group: Members
Posts: 67
Joined: 6-September 05
Member No.: 24363



QUOTE (Anakunda @ Aug 14 2012, 22:24) *
QUOTE (jetpower @ Aug 14 2012, 22:15) *
AAC has less holes in high freq, also are you a bat?


No not a bat tongue.gif does "less holes in high freq" mean a worse encode quality? I think the hard cutoff at ~19.5kHz by AAC is no good but not sure about that.
I'm curious if iTunes does their encodes using the same QuickTime library or something else. Looked at iTunes original track which otherwise was a noticeably higher bitrate but there wasnot such a hard cutoff. Finally I'm not too impressed by the spectral of this TVBR.


I can hear up to 17khz, so this 19.5khz is more than enough for me. Holes/darker parts means less energy.
Go to the top of the page
+Quote Post
LigH
post Aug 15 2012, 07:49
Post #203





Group: Members
Posts: 156
Joined: 20-November 01
Member No.: 503



"A higher cutoff frequency" is not the only criterion for "subjectively better quality"; that would rather be a general "less annoying loss". What if the high frequency range prevents the codec from preserving quality in lower, more audible ranges?

A more variable frequency spectrum may be a sign for a more "optimistic" psycho-acoustic model; this is neither a guarantee for better or worse quality on its own. Just a proof for a different algorithm. It may sound more or less lossy, depending on many factors.

If subjective impression could be measured and quantized more directly than in a "mass ABX test", we could have an objective quality metric.

This post has been edited by LigH: Aug 15 2012, 07:51


--------------------
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum
Go to the top of the page
+Quote Post
Anakunda
post Aug 15 2012, 08:01
Post #204





Group: Members
Posts: 450
Joined: 24-November 08
Member No.: 63072



Vorbis achieves higher frequencies but probably at cost of worse reproduction in higher range.
So I guess it's not possible to say if QAAC model is better or worse.
Go to the top of the page
+Quote Post
pururin
post Aug 22 2012, 09:56
Post #205





Group: Members
Posts: 8
Joined: 3-March 12
Member No.: 97532



Is it normal that encoding 5.1 audio in Multi-threading mode is slower than single threading?
Total time used by Multi-thread encoding (either 2 or 4 instances at the same time) is slower than consecutive single-thread encoding everytime I've tried. And total CPU usage is quite a bit low during multi-thread encoding with enough ram and hdd power left. This doesn't happen with stereo audio, with 2.0 tracks CPU usage skyrockets to full 50 or 100% and the work's blazing fast.

Simply put, one by one work is faster for 5.1 audio. Kinda weird? (My system is i5-2540m Sandybridge, Win7 32bit)

This post has been edited by pururin: Aug 22 2012, 10:11
Go to the top of the page
+Quote Post
nu774
post Aug 23 2012, 01:46
Post #206





Group: Developer
Posts: 514
Joined: 22-November 10
From: Japan
Member No.: 85902



QuickTime/CoreAudio encoder itself always works on a single thread.
When --threading option of qaac is set, encoder and decoder/DSP run on two different threads (one thread for each).
Therefore, --threading will give you faster speed only when you do some heavy work on decoder/DSP side.



Go to the top of the page
+Quote Post
eahm
post Aug 27 2012, 18:34
Post #207





Group: Members
Posts: 1037
Joined: 11-February 12
Member No.: 97076



[qaac] release 1.40 (refalac 0.51)
posted 5 hours ago by nu 774 [ updated 4 hours ago ]
Update libsoxrate to 0.30 (merged update on rate effect of SoX: Speed up on down sampling).

Due to ABI change on libsoxrate.dll, new qaac/refalac is incompatible with older libsoxrate.dll versions.

https://sites.google.com/site/qaacpage/home

Thanks for the update.

This post has been edited by eahm: Aug 27 2012, 18:45


--------------------
/lwAsIimz
Go to the top of the page
+Quote Post
neothe0ne
post Sep 1 2012, 02:50
Post #208





Group: Members
Posts: 295
Joined: 25-September 05
Member No.: 24684



I'm using qaac 1.39 and am having random problems with encoding FLAC to AAC. I see 26x+ speed (I saw sustained 40x for a bit before it slowed down) most of the time, but on some files the encoder will progress at a sluggish ~1.2 to ~1.7x speed, but the real kicker is the resulting file is silence. This is completely random and an unknown number of retries / accessing data from a different part of the disk after X minutes (that's a really long time) will "fix" the problem and let qaac actually encode something that's not silence. Foobar2000 can play the FLAC file fine, of course, and the FLAC file is not corrupted.

Anyone know what's going on? Non-ASCII/long filenames/locations, FLAC tags, and inside/outside archives don't seem to be the problem after some testing.

This post has been edited by neothe0ne: Sep 1 2012, 02:54
Go to the top of the page
+Quote Post
neothe0ne
post Sep 1 2012, 20:24
Post #209





Group: Members
Posts: 295
Joined: 25-September 05
Member No.: 24684



QUOTE (neothe0ne @ Aug 31 2012, 21:50) *
I'm using qaac 1.39 and am having random problems with encoding FLAC to AAC. I see 26x+ speed (I saw sustained 40x for a bit before it slowed down) most of the time, but on some files the encoder will progress at a sluggish ~1.2 to ~1.7x speed, but the real kicker is the resulting file is silence. This is completely random and an unknown number of retries / accessing data from a different part of the disk after X minutes (that's a really long time) will "fix" the problem and let qaac actually encode something that's not silence. Foobar2000 can play the FLAC file fine, of course, and the FLAC file is not corrupted.

Anyone know what's going on? Non-ASCII/long filenames/locations, FLAC tags, and inside/outside archives don't seem to be the problem after some testing.

Apparently, this slow speed silence bug has something to do with using --lowpass 19700? (I'm only using this for TVBR 100+... from a glance at the spectrographs it doesn't seem to change the distribution of bits at all, just imposes a hard wall which saves a couple hundred KB per song.)

Is this a known bug of qaac and/or Core Audio?
Go to the top of the page
+Quote Post
Anakunda
post Sep 1 2012, 20:29
Post #210





Group: Members
Posts: 450
Joined: 24-November 08
Member No.: 63072



QUOTE (neothe0ne @ Sep 1 2012, 21:24) *
Is this a known bug of qaac and/or Core Audio?


Can you share the original file converting from?
Go to the top of the page
+Quote Post
nu774
post Sep 2 2012, 04:05
Post #211





Group: Developer
Posts: 514
Joined: 22-November 10
From: Japan
Member No.: 85902



It's impossible to fix a bug (if any) if I cannot reproduce it.
If you can reproduce it, please share the problematic file and write precise step to reproduce it (command line, etc).
Go to the top of the page
+Quote Post
neothe0ne
post Sep 2 2012, 07:14
Post #212





Group: Members
Posts: 295
Joined: 25-September 05
Member No.: 24684



QUOTE (nu774 @ Sep 1 2012, 23:05) *
It's impossible to fix a bug (if any) if I cannot reproduce it.
If you can reproduce it, please share the problematic file and write precise step to reproduce it (command line, etc).


It's not a file - it's every file, FLAC or WAV, any location. When the bug kicks in and I let the process finish encoding at ~2x instead of 40-50x, the resulting file is ~22 kbps of the correct length, but complete silence. (instead of ~200 kbps) As I said, after an unknown number of playback / disk reading changes, the said files can be encoded properly again. It's completely random but affects every single file. I've now even had it encode the first 2 tracks of an album as slow silence (with proper length), but successfully encode the other 10 tracks of the album.

my foobar2000 arguments are
CODE
-V 109 --lowpass 19700 - -o %d


I don't think this bug happens when I use -V 91 and don't set a lowpass (the default lowpass for -91 is lower than 19.7). So my thoughts are it's the lowpass.
Go to the top of the page
+Quote Post
Anakunda
post Sep 2 2012, 08:30
Post #213





Group: Members
Posts: 450
Joined: 24-November 08
Member No.: 63072



QUOTE (neothe0ne @ Sep 2 2012, 08:14) *
I don't think this bug happens when I use -V 91 and don't set a lowpass (the default lowpass for -91 is lower than 19.7). So my thoughts are it's the lowpass.


Your command line isnot producing any faulty output. Check if qaac using proper libsoxrate dll. Also try append --ignorelength to command line if encoding through PIPE.
Go to the top of the page
+Quote Post
neothe0ne
post Sep 5 2012, 05:58
Post #214





Group: Members
Posts: 295
Joined: 25-September 05
Member No.: 24684



QUOTE (Anakunda @ Sep 2 2012, 02:30) *
QUOTE (neothe0ne @ Sep 2 2012, 08:14) *
I don't think this bug happens when I use -V 91 and don't set a lowpass (the default lowpass for -91 is lower than 19.7). So my thoughts are it's the lowpass.


Your command line isnot producing any faulty output. Check if qaac using proper libsoxrate dll. Also try append --ignorelength to command line if encoding through PIPE.

If I try a wrong libsoxrate.dll, qaac crashes after 1 second and won't encode anything at all.

What does "encoding through PIPE" mean? A filepath containing the "|" aka flacs inside zip/rar packages?
Go to the top of the page
+Quote Post
LigH
post Sep 5 2012, 09:15
Post #215





Group: Members
Posts: 156
Joined: 20-November 01
Member No.: 503



Using the command line interpreter and the "pipe symbol" (|) is one way to make a pipe, a connected redirection of the output of one application (>) into the input of another application (<). It can also be built with OS functions.

"Pipe aware" CLI applications usually support a single dash (-) as placeholder for standard input and output file handles instead of file names for disk files. In this case, they "print the output file content to the standard output" instead of using disk file operations; this requires specific options under Windows to support correct binary output.

STDIN = file handle 0 (usually assigned to the console, keyboard)
STDOUT = file handle 1 (usually assigned to the console, monitor)
STDERR = file handle 2 (usually assigned to the console, monitor)

The standard error handle can be redirected too, using its number 2 preceding the redirector (e.g. '2>'), which can be useful to store error messages into a log file.

This post has been edited by LigH: Sep 5 2012, 09:17


--------------------
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum
Go to the top of the page
+Quote Post
sundance
post Sep 5 2012, 10:50
Post #216





Group: Members
Posts: 163
Joined: 17-April 02
Member No.: 1804



@nu774
Is there a technical reason why e.g. MP3 files are not supported as input for QAAC?
I thought that libsndfile does support MP3...

This post has been edited by sundance: Sep 5 2012, 10:52
Go to the top of the page
+Quote Post
LigH
post Sep 5 2012, 11:07
Post #217





Group: Members
Posts: 156
Joined: 20-November 01
Member No.: 503



Why recoding a worse format which already suffers from psychoacoustic loss?


--------------------
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum
Go to the top of the page
+Quote Post
Anakunda
post Sep 5 2012, 11:10
Post #218





Group: Members
Posts: 450
Joined: 24-November 08
Member No.: 63072



QUOTE (sundance @ Sep 5 2012, 11:50) *
Is there a technical reason why e.g. MP3 files are not supported as input for QAAC?

Transcoding from lossy formats is forbidden.
Go to the top of the page
+Quote Post
sundance
post Sep 5 2012, 11:12
Post #219





Group: Members
Posts: 163
Joined: 17-April 02
Member No.: 1804



QUOTE (LigH @ Sep 5 2012, 12:07) *
Why recoding a worse format which already suffers from psychoacoustic loss?


E.g. to recode an MP3 audiobook @ 192 kbps / multiple files to an iPod compatible M4B file with chapters @ 48 kbps...
Go to the top of the page
+Quote Post
sundance
post Sep 5 2012, 11:17
Post #220





Group: Members
Posts: 163
Joined: 17-April 02
Member No.: 1804



QUOTE (Anakunda @ Sep 5 2012, 12:10) *
QUOTE (sundance @ Sep 5 2012, 11:50) *
Is there a technical reason why e.g. MP3 files are not supported as input for QAAC?

Transcoding from lossy formats is forbidden.

Forbidden? By law? LOL!
I asked for technical, not ideological/political/religious reasons...
Go to the top of the page
+Quote Post
LigH
post Sep 5 2012, 11:24
Post #221





Group: Members
Posts: 156
Joined: 20-November 01
Member No.: 503



HydrogenAudio has higher ideological standards. wink.gif

A workaround could be piping {lame --decode *.mp3 - | qaac -i ... -o *.m4a -}.


--------------------
http://forum.gleitz.info - das deutsche doom9/Gleitz-Forum
Go to the top of the page
+Quote Post
sundance
post Sep 5 2012, 11:39
Post #222





Group: Members
Posts: 163
Joined: 17-April 02
Member No.: 1804



QUOTE (LigH @ Sep 5 2012, 12:24) *
A workaround could be piping {lame --decode *.mp3 - | qaac -i ... -o *.m4a -}.

I've already considered that, but I couldn't find a way to use piping in combination with QAAC's --concat switch.
So I ended up with first converting all the MP3 stuff to WAV and then running "QAAC --concat *.wav -o audiobook.m4b" which uses more time and temp disc space than neccessary...
Go to the top of the page
+Quote Post
nu774
post Sep 5 2012, 12:22
Post #223





Group: Developer
Posts: 514
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (sundance @ Sep 5 2012, 18:50) *
@nu774
Is there a technical reason why e.g. MP3 files are not supported as input for QAAC?
I thought that libsndfile does support MP3...

AFAIK libsndfile doesn't support MP3, but CoreAudio does. As far as using CoreAudio built-in decoder, license/patent would not matter.
I don't want to support MP3 input mainly because it's not important at all for a command line AAC encoder, while implementing it is a pain for me (handling of encoder delays, etc..) .
Go to the top of the page
+Quote Post
sundance
post Sep 5 2012, 13:08
Post #224





Group: Members
Posts: 163
Joined: 17-April 02
Member No.: 1804



QUOTE (nu774 @ Sep 5 2012, 13:22) *
I don't want to support MP3 input (...) implementing it is a pain for me (handling of encoder delays, etc..) .

I can perfectly understand your point of view.
And (unless another work-around for my "single audiobook conversion problem" surfaces, I'll stick to my intermediate WAV solution...

Or, does anyone have a solution (command line tool for Windows) to concat multiple m4a files to a single m4b file with chapter marks at file boundaries?
Go to the top of the page
+Quote Post
thespacepope72
post Sep 10 2012, 09:03
Post #225





Group: Members
Posts: 8
Joined: 17-November 06
Member No.: 37674



SITUATION: I ripped all of my CDs to FLAC about 4 years ago using EAC. I felt like FLAC was the best option at the time and still may be however I have recently moved to iPhones (wife's decision) with iOS 5.1.1 so syncing FLAC files to the iPhone using foobar2000 is not possible.

PROPOSED SOLUTION: I am thinking about converting my FLAC to ALAC using foobar2000 and qaac so I can use iTunes to sync the files to the iPhone.

CONCERN: It is my understanding that prior to November 2011, ALAC was a closed format and ALAC encoders were reverse engineered.

QUESTIONS: Is qaac based on the reverse engineered ALAC encoder or is it based on the "official" specification? I would be disappointed if I converted my FLAC collection to an "unofficial" ALAC implementation only to have something incompatible about the files at some point in the future. I am not technical enough to understand some of the specifications but I know I want my files archived in some lossless format.

OTHER CONSIDERATIONS: I realize that I could use MediaMonkey to sync the files but that may only last until Apple changes something in their software to break syncing with MediaMonkey. Additionally, I don't think that the free version of MediaMonkey does transcoding on the fly. I know I could also just convert my FLAC to mp3 and keep both copies of the files but maintaining two versions of the same file sounds like torture to me.
Go to the top of the page
+Quote Post

28 Pages V  « < 7 8 9 10 11 > » 
Reply to this topicStart new topic
8 User(s) are reading this topic (8 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 31st July 2014 - 01:13