Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 26th April 2012, 19:21   #681  |  Link
Taurus
Registered User
 
Taurus's Avatar
 
Join Date: Mar 2002
Location: Krautland
Posts: 776


Thank you!
Taurus is offline   Reply With Quote
Old 28th April 2012, 19:52   #682  |  Link
pururin
Registered User
 
Join Date: Dec 2011
Posts: 54
4.04 Cool

Few questions : Do I need to use Lamexp's specific qaac addin or can I replace qaac file to newer version?

If not, how do I track the addin update easily?

qaac quality scale seems a bit confuse to me. I suppose q 0.75 in the gui is around tvbr Q90?
(Actually there're only 15 steps, why would Apple makes it Q0-127 )
pururin is offline   Reply With Quote
Old 29th April 2012, 15:49   #683  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,776
Quote:
Originally Posted by pururin View Post
Few questions : Do I need to use Lamexp's specific qaac addin or can I replace qaac file to newer version?
Should be possible, unless the new version has changed the interface in a way that breaks compatibility.

Quote:
Originally Posted by pururin View Post
If not, how do I track the addin update easily?
I will update the add-in as needed.

Quote:
Originally Posted by pururin View Post
qaac quality scale seems a bit confuse to me. I suppose q 0.75 in the gui is around tvbr Q90?
The quality scale for VBR mode in the GUI is 0.00 to 1.00.

As LameXP supports various AAC encoders, LameXP will map the 0.00-1.00 scale to the "internal" representation of the individual encoder.

For the QAAC encoder the internal scale (as least the one that is exposed to the calling application) is 0-127, LameXP cannot do anything about that.

Consequently the 0.00-1.00 scale will be mapped to 0-127 by LameXP.

Quote:
Originally Posted by pururin View Post
(Actually there're only 15 steps, why would Apple makes it Q0-127 )
Ask them

(They probably thought that making the quality scale a 7-Bit value should be sufficiently fine-grained for all future versions, even if the current version has fewer quality steps)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 29th April 2012 at 21:25.
LoRd_MuldeR is offline   Reply With Quote
Old 29th April 2012, 21:15   #684  |  Link
pururin
Registered User
 
Join Date: Dec 2011
Posts: 54
Thanks you Lord.
pururin is offline   Reply With Quote
Old 1st May 2012, 15:34   #685  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 949
Code:
LameXP v4.04 (Build #988), compiled on 2012-04-26 at 13:23:48

-------------------------------

C:/DOCUME~1/ADMINI~1/CONFIG~1/Temp/34ed0c6bfc8349aaae62a81420ce853e/lamexp_valdec.exe "C:\audio_track.ac3" ↩
-w D:\Temp\812dfc4c29c1443d9ddbb1caa2659822.wav

Opening audio output PCM16 3/2.1 (5.1) 48000...
---------------------------------------
Streams found: 2
Frames/errors: 263716/0
System time: 221187ms
Process time: 129343ms
Approx. 1.53% realtime CPU usage

Exited with code: 0x0000

-------------------------------

C:/DOCUME~1/ADMINI~1/CONFIG~1/Temp/34ed0c6bfc8349aaae62a81420ce853e/lamexp_sox.exe ↩
--i D:/Temp/812dfc4c29c1443d9ddbb1caa2659822.wav

C:\DOCUME~1\ADMINI~1\CONFIG~1\Temp\34ed0c6bfc8349aaae62a81420ce853e\lamexp_sox.exe FAIL formats: ↩
can't open input file `D:/Temp/812dfc4c29c1443d9ddbb1caa2659822.wav': WAVE: RIFF header not found

Exited with code: 0x0001
Quote:
Originally Posted by nautilus7 View Post
I'm trying to encode a 5.1 file using avs input.

My script plays fine in mpc:
Code:
l=WAVSource("l.wav")
r=WAVSource("r.wav")
c=WAVSource("c.wav")
lfe=WAVSource("lfe.wav")
ls=WAVSource("ls.wav")
rs=WAVSource("rs.wav")

MergeChannels(l,r,c,lfe,ls,rs)
Lame-xp fails with this error massage:
Code:
LameXP v4.02 (Build #578), compiled at 2011-06-14

-------------------------------

C:/Users/NAUTIL~1/AppData/Local/Temp/d2d906dac226430bb5d0fee4458f206d/tool_avs2wav.exe ↩
C:\sintel\sintel-master-51-flac\51.master.avs ↩
C:\Users\NAUTIL~1\AppData\Local\Temp\d2d906dac226430bb5d0fee4458f206d\e36981fe6dde42c2bb51452c114e12c5.wav

avs2wav v1.2 [May 24 2011]
by Jory Stone <jcsston@toughguy.net>, updates by LoRd_MuldeR <mulder2@gmx.de>
Input: C:\sintel\sintel-master-51-flac\51.master.avs
Output: C:\Users\NAUTIL~1\AppData\Local\Temp\d2d906dac226430bb5d0fee4458f206d\e36981fe6dde42c2bb51452c114e12c5.wav
Checking Avisynth...
Done
Analyzing input file...
Done
Opening output file... Done
[Audio Info]
TotalSamples: 42624000
TotalSeconds: 888
SamplesPerSec: 48000
BitsPerSample: 16
Channels: 6
AvgBytesPerSec: 576000
Dumping audio data, please wait:
AVIStreamRead succeeded, but did not return any samples!
Failed to dump audio stream (status -4). Terminating!

Exited with code: 0xFFFFFFFC
Same here...
and Comodo Firewall doesn't let me set LameXP as a trust program from the pop up notifier, this is always an option when using programs.

more funny facts:
encoding a wav file requires decoding the wav
that translates to-> a 3Gb audio wav file from a 2h movie is instantly duplicated in the temporal folder, and if you use normalization or any other post filter, there will be a third instance of the file, that is almost 10Gb reading/writting to HDD and required free space.

Last edited by LoRd_MuldeR; 1st May 2012 at 17:33. Reason: Broke some long line, so the layout doesn't get destroyed
Dogway is offline   Reply With Quote
Old 1st May 2012, 17:52   #686  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,776
Quote:
Originally Posted by Dogway View Post
Code:
LameXP v4.04 (Build #988), compiled on 2012-04-26 at 13:23:48

-------------------------------

C:/DOCUME~1/ADMINI~1/CONFIG~1/Temp/34ed0c6bfc8349aaae62a81420ce853e/lamexp_valdec.exe "C:\audio_track.ac3" ↩
-w D:\Temp\812dfc4c29c1443d9ddbb1caa2659822.wav

Opening audio output PCM16 3/2.1 (5.1) 48000...
---------------------------------------
Streams found: 2
Frames/errors: 263716/0
System time: 221187ms
Process time: 129343ms
Approx. 1.53% realtime CPU usage

Exited with code: 0x0000

-------------------------------

C:/DOCUME~1/ADMINI~1/CONFIG~1/Temp/34ed0c6bfc8349aaae62a81420ce853e/lamexp_sox.exe ↩
--i D:/Temp/812dfc4c29c1443d9ddbb1caa2659822.wav

C:\DOCUME~1\ADMINI~1\CONFIG~1\Temp\34ed0c6bfc8349aaae62a81420ce853e\lamexp_sox.exe FAIL formats: ↩
can't open input file `D:/Temp/812dfc4c29c1443d9ddbb1caa2659822.wav': WAVE: RIFF header not found

Exited with code: 0x0001
Looks like either Valdec produced an invalid output Wave file or SoX didn't like the Wave file produced by Valdec for whatever reason.

Can you provide an AC-3 file to reproduce?

Quote:
Originally Posted by Dogway View Post
Quote:
Originally Posted by nautilus7 View Post
I'm trying to encode a 5.1 file using avs input.

My script plays fine in mpc:
Code:
l=WAVSource("l.wav")
r=WAVSource("r.wav")
c=WAVSource("c.wav")
lfe=WAVSource("lfe.wav")
ls=WAVSource("ls.wav")
rs=WAVSource("rs.wav")

MergeChannels(l,r,c,lfe,ls,rs)
Lame-xp fails with this error massage:
Code:
LameXP v4.02 (Build #578), compiled at 2011-06-14

-------------------------------

C:/Users/NAUTIL~1/AppData/Local/Temp/d2d906dac226430bb5d0fee4458f206d/tool_avs2wav.exe ↩
C:\sintel\sintel-master-51-flac\51.master.avs ↩
C:\Users\NAUTIL~1\AppData\Local\Temp\d2d906dac226430bb5d0fee4458f206d\e36981fe6dde42c2bb51452c114e12c5.wav

avs2wav v1.2 [May 24 2011]
by Jory Stone <jcsston@toughguy.net>, updates by LoRd_MuldeR <mulder2@gmx.de>
Input: C:\sintel\sintel-master-51-flac\51.master.avs
Output: C:\Users\NAUTIL~1\AppData\Local\Temp\d2d906dac226430bb5d0fee4458f206d\e36981fe6dde42c2bb51452c114e12c5.wav
Checking Avisynth...
Done
Analyzing input file...
Done
Opening output file... Done
[Audio Info]
TotalSamples: 42624000
TotalSeconds: 888
SamplesPerSec: 48000
BitsPerSample: 16
Channels: 6
AvgBytesPerSec: 576000
Dumping audio data, please wait:
AVIStreamRead succeeded, but did not return any samples!
Failed to dump audio stream (status -4). Terminating!

Exited with code: 0xFFFFFFFC
Same here...
Well, there is not much I can do on my side, if AVIStreamRead() returns a code that indicates "success" but the number of samples returned is zero.

...except for reporting the "contradictory" state that has been encountered to the user

Quote:
Originally Posted by Dogway View Post
and Comodo Firewall doesn't let me set LameXP as a trust program from the pop up notifier, this is always an option when using programs.
Well, I would recommend to send a bug report to Comodo, if the "white-list" doesn't work as expected.

Quote:
Originally Posted by Dogway View Post
more funny facts:
encoding a wav file requires decoding the wav
that translates to-> a 3Gb audio wav file from a 2h movie is instantly duplicated in the temporal folder, and if you use normalization or any other post filter, there will be a third instance of the file, that is almost 10Gb reading/writting to HDD and required free space.
Depending on what exactly you are doing, a temporary "working copy" needs to be created, even if both the, source file and the output file, are Wave files.

For example this will be necessary, if any filters are applied...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 1st May 2012 at 17:58.
LoRd_MuldeR is offline   Reply With Quote
Old 1st May 2012, 18:48   #687  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 949
Quote:
Originally Posted by LoRd_MuldeR View Post
Looks like either Valdec produced an invalid output Wave file or SoX didn't like the Wave file produced by Valdec for whatever reason.

Can you provide an AC-3 file to reproduce?
I tested the sample (cut ac3) file I was going to send you and it worked so I don't think it could be worth... but if you mind, the produced (intended) file was a 3Gb wav, there might be some hint...

Quote:
Originally Posted by LoRd_MuldeR View Post
Well, there is not much I can do on my side, if AVIStreamRead() returns a code that indicates "success" but the number of samples returned is zero.

...except for reporting the "contradictory" state that has been encountered to the user
I don't know about that, I just wonder if avs processing has ever worked or not.

Quote:
Originally Posted by LoRd_MuldeR View Post
Well, I would recommend to send a bug report to Comodo, if the "white-list" doesn't work as expected.
I don't think Comodo keeps track of all the hobbyist applications I install (I doubt), but yours is the only one that didn't offer the option to "trust application". In this regard I think it has more to do with some nature of the program rather than Comodo white-listing, I still can go to Comodo options and manual white list LameXP, doable but a bit annoying. Just letting you know some curiosities of LameXP.

Quote:
Originally Posted by LoRd_MuldeR View Post
Depending on what exactly you are doing, a temporary "working copy" needs to be created, even if both the, source file and the output file, are Wave files.

For example this will be necessary, if any filters are applied...
Despite I still don't understand why a full copy of the file needs to be done (megui didn't do, behappy doesn't either if I'm not wrong...) what I refer here is that in the decoding stage of the wave file an exact wave file copy is done, this is before any filtering, just decoding, then a second copy is performed for the filtering dummy (normalisation, whatever).

Dogway is offline   Reply With Quote
Old 1st May 2012, 19:10   #688  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,776
Quote:
Originally Posted by Dogway View Post
I tested the sample (cut ac3) file I was going to send you and it worked so I don't think it could be worth... but if you mind, the produced (intended) file was a 3Gb wav, there might be some hint...
I think I know what the problem is:

Wave files (and RIFF files in general) can't grow lager than 4 GB. The limit might even be 2 GB, if the application interprets the chunk "size" field as signed.

There is some confusion about how the "size" field has to be interpreted, but more than 4 GB will never be possible with Wave files. There is no easy workaround for this restriction.

I think Valdec will create a RF64 file rather than a Wave/RIFF file, if the size becomes too large. And it seems that SoX doesn't support RF64 files. The same applies to most tools!

(The only real solution would be switching to "RF64" as the common intermediate format. But as long as most of the audio tools don't support RF64, this is a lost case)

Quote:
Originally Posted by Dogway View Post
I don't know about that, I just wonder if avs processing has ever worked or not.
My avs2wav tool, based on the tool by Jory Stone, does work for me - most of the time. There only seem to be certain configuration that trigger the strange error.

I don't know why this happens. Actually I don't think this is supposed to happen at all...

Quote:
Originally Posted by Dogway View Post
I don't think Comodo keeps track of all the hobbyist applications I install (I doubt), but yours is the only one that didn't offer the option to "trust application". In this regard I think it has more to do with some nature of the program rather than Comodo white-listing, I still can go to Comodo options and manual white list LameXP, doable but a bit annoying. Just letting you know some curiosities of LameXP.
Maybe Comodo isn't prepared for the fact that LameXP is a front-end application and will launch other programs in the background.

There is no workaround, because this is "by design". Only way would be adding an option to Comodo that allows whitelisting a program and all child-processes it will create.

Quote:
Originally Posted by Dogway View Post
Despite I still don't understand why a full copy of the file needs to be done (megui didn't do, behappy doesn't either if I'm not wrong...) what I refer here is that in the decoding stage of the wave file an exact wave file copy is done, this is before any filtering, just decoding, then a second copy is performed for the filtering dummy (normalisation, whatever).
The processing steps in LameXP are as follows:
Decode source file to temporary Wave file > apply all filters on the temporary Wave file > encode temporary Wave file to final output

Actually there is a "shortcut" implemented in LameXP:
We can skip creating a temporary Wave file, if (and only if) the selected encoder can read/decode the individual source file directly.

This "shortcut" cannot be use if any filters are applied, for obvious reasons...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 1st May 2012 at 19:16.
LoRd_MuldeR is offline   Reply With Quote
Old 2nd May 2012, 22:08   #689  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Posts: 2,010
Quote:
I think Valdec will create a RF64 file rather than a Wave/RIFF file, if the size becomes too large. And it seems that SoX doesn't support RF64 files. The same applies to most tools!

(The only real solution would be switching to "RF64" as the common intermediate format. But as long as most of the audio tools don't support RF64, this is a lost case)
I made a few tests trying to reproduce Dogway's problem, and it is absolutely clear that SoX cannot use large WAV files above 4GB. When I used an older version of ValDec which does not support the WavFile_Extensible format Sox would not crap out with an error, but would instead cut off the source file after 15 minutes. Hopeless...

But if the desired target format is something other than Wav then any BeSweet based app can do this because no intermediate Wav file is used. I tried to convert a 6-ch AC3 file (duration almost 3 hours) to a 6-ch normalized AAC file, and BeLight had no problems with this conversion. (HeadAC3he could not do it, it would hang two thirds into the conversion)


Cheers
manolito
manolito is offline   Reply With Quote
Old 2nd May 2012, 22:22   #690  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,776
Quote:
Originally Posted by manolito View Post
I made a few tests trying to reproduce Dogway's problem, and it is absolutely clear that SoX cannot use large WAV files above 4GB. When I used an older version of ValDec which does not support the WavFile_Extensible format Sox would not crap out with an error, but would instead cut off the source file after 15 minutes. Hopeless...
As explained before, Wave files cannot grow larger than 4 GB. That's an inherent limitation of the Wave/RIFF format.

If you ever see a Wave file that is larger than 4 GB, then this is either a RF64 file with a "wrong" file extension or it's a non-standard Wave file.

The former is isn't widely supported yet, the latter is predestinated to cause all kinds of problems...

Quote:
Originally Posted by manolito View Post
But if the desired target format is something other than Wav then any BeSweet based app can do this because no intermediate Wav file is used. I tried to convert a 6-ch AC3 file (duration almost 3 hours) to a 6-ch normalized AAC file, and BeLight had no problems with this conversion. (HeadAC3he could not do it, it would hang two thirds into the conversion)
Well, if you don't create an intermediate Wave file, then of course you don't have to worry about the file size limit of Wave files.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 2nd May 2012 at 22:38.
LoRd_MuldeR is offline   Reply With Quote
Old 2nd May 2012, 22:43   #691  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Posts: 2,010
Quote:
Originally Posted by LoRd_MuldeR View Post
Well, if you don't create an intermediate Wave file, then of course you don't have to worry about the file size limit of Wave files.
Which leads me to the question if LameXP really should depend on intermediate Wave files for filtering. I am perfectly aware of the fact that this is the core design of LameXP in order to achieve maximum flexibility, but for a practical minded person like me the main objective is always "Does it work?" If not, I need to change the design... Oops, getting a little philosophical here



Cheers
manolito
manolito is offline   Reply With Quote
Old 2nd May 2012, 22:59   #692  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,776
Using Wave files as the intermediate format is the most flexible and most compatible solution, because all CLI decoders that I am aware of at least can write a Wave file and all CLI encoders at least can read from a Wave file. It seems Wave files are the "lowest common denominator" for audio tools. If we don't want to use intermediate files, then we need to pass the uncompressed data via pipe. Even if we assume all decoders can write to STDOUT and all encoders can read from STDIN, which in reality is not the case, what is the format we send over the pipe? Do we send "raw" PCM samples? Or do we send send some kind of "fake" Wave header? If we send "raw" samples, how to indicate the sample format and the number of channels? And how to indicate the total number of samples, so that the encoder can report progress? Will using a pipe work with 2-Pass filters in SoX? After all this will introduce more new problems than it solves, I think...

(And this doesn't even take into account the immense amount of work that would be required to re-write everything ^^)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 2nd May 2012 at 23:11.
LoRd_MuldeR is offline   Reply With Quote
Old 4th May 2012, 19:49   #693  |  Link
Paddy97
Registered User
 
Join Date: Oct 2006
Posts: 70
Is there a way to make LameXP transfer the embedded cover art in a flac file when converting to AAC/MP3?
Paddy97 is offline   Reply With Quote
Old 4th May 2012, 19:55   #694  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,776
Should be possible, yes.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 4th May 2012, 20:02   #695  |  Link
Paddy97
Registered User
 
Join Date: Oct 2006
Posts: 70
Quote:
Originally Posted by LoRd_MuldeR View Post
Should be possible, yes.
Guessed so :-) On closer inspection its working for me if I use MP3 as output but not AAC using QT.

Last edited by Paddy97; 4th May 2012 at 20:05.
Paddy97 is offline   Reply With Quote
Old 4th May 2012, 20:20   #696  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,776
Quote:
Originally Posted by Paddy97 View Post
Guessed so :-) On closer inspection its working for me if I use MP3 as output but not AAC using QT.
LameXP will re-embed cover art, if the selected encoder supports that. LAME does. QAAC does not. Use Nero AAC

(It may be possible to add the cover art to the QAAC-encoded MP4 file later with some other tool, but LameXP does not implement that currently)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 4th May 2012 at 20:37.
LoRd_MuldeR is offline   Reply With Quote
Old 4th May 2012, 23:11   #697  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Posts: 2,010
Quote:
(The only real solution would be switching to "RF64" as the common intermediate format. But as long as most of the audio tools don't support RF64, this is a lost case)
And it looks like this is not gonna happen anytime soon.

I found a request for SoX to support RF64 plus the answer from Chris Bagwell (it is from 2006), and it does not sound encouraging:
Quote:
Chris Bagwell | 31 Mar 03:02
Re: New file format? (RF64)
It would be nice to at least see the WAVE64 portion to be rolled into
the current WAV handler. I've seen several requests for > 4gig audio
files in WAV format.

It should be simple enough to add support for both WAVE64 and RF64 since
the code to parse chunks already exists in the wav.c. Just need to
tweak it some to work with these other formats. I'll have to leave that
as an exercise for someone else though.

Chris

Which brings us back to the hard sad facts:

Unless LameXP changes its design fundamentally, it does (and will) not support multichannel source files with a duration of more than 2 hours.

For a 6-ch AC3 source file (16bits, 48 kHz) the threshold is at 2 hours 4 minutes. Audio files which are longer than this are quite common these days. This really limits the usefulness of LameXP.



Cheers
manolito
manolito is offline   Reply With Quote
Old 4th May 2012, 23:50   #698  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,776
Well, unless there is a feasible solution to overcome for the 4 GB limit (i.e. a solution that works with all decoders, with all encoders, with all filters and that can be implemented with acceptable effort) there isn't much I can do
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 5th May 2012, 07:58   #699  |  Link
Paddy97
Registered User
 
Join Date: Oct 2006
Posts: 70
Quote:
Originally Posted by LoRd_MuldeR View Post
LameXP will re-embed cover art, if the selected encoder supports that. LAME does. QAAC does not. Use Nero AAC

(It may be possible to add the cover art to the QAAC-encoded MP4 file later with some other tool, but LameXP does not implement that currently)
It was this study that intrigued me from the beginning to start converting to AAC with QT instead of Nero.

http://listening-tests.hydrogenaudio...a/results.html
Paddy97 is offline   Reply With Quote
Old 13th May 2012, 14:30   #700  |  Link
Przemek_Sperling
Registered User
 
Join Date: Jun 2009
Location: Poland
Posts: 120
Is any chance that LameXP will use the Fraunhofer AAC dll library (used by Winamp) with the aacPlus wrapper?
Przemek_Sperling is offline   Reply With Quote
Reply

Tags
aac, aotuv, flac, lame, lamexp, mp3, mp4, ogg, oggenc, opus, vorbis

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 03:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.