I don't know why MediaInfo shows something like that as "Sample Count", but I think it's not problem of qaac.You can dump mp4 file structure by tools like mp4box or boxdumper (of L-SMASH), which is FAR more reliable than MediaInfo when you want to inspect MP4.

Thanks so much for the explanation. "mp4box -diso" does shows the correct value of 127772672 whereas MediaInfo shows 127772688 for the same file.Seems that MediaInfo is reporting the wrong values and I have reported this bug on the MediaInfo forum.

"mp4box.exe -diso" shows millisecond duration under "SampleCount" and Sample Count under "Duration" in its XML output. The XML tag names are switched in mp4box but the values are right.

I want to convert 5.1 AC3 to 5.1 AAC. But i don't know how to "convert" the ac3-file to a supportet inputfile for qaac. Can somebody tell me a working commandline? (like ffmpeg ----many options---- | qaac ---some more options---)?

The last two options on the qaac side are of course optional. I would recommend --verbose at least as qaac then displays the amt of channels you're dealing with. "-i" tells it to ignore wav headers (which will give you the wrong length and muck things up).

On the eac3to side I didn't specify any flags, but you might want to use -down16 when using TrueHD input (let eac3to handle the dithering). If you're converting from 6.1 or 7.1 and want 5.1 output, you should also use -down6.

QUOTE

and i think the reason could be, that I have some 2.0 parts in the 5.1 audio source.

I'm not sure if that's technically possible or makes any sense? Having silence in every channel except for front L/R does not a 2.0 source make.

Note that eac3to uses ffmpeg to decode ac3 by default. I'm not sure if using it will help you at all.

You can also have QAAC output *.m4a by omitting "--adts"; I would prefer it in an MP4 container if it will be multiplexed later.

Yeah, it really depends on the muxer. I sometimes use l-smash and it only supports adts, while mkvmerge supports both. And because of the "--no-delay" switch no gapless info is needed. I prefer that as it does not rely on the player using the proper delay, because some players just don't.

Thanks for the tip, though it does not seem to make a difference for ffmpeg's ac3 decoder. Usually I use eac3to as suggested by LastSilmaril because the author does keep proper bit depth conversions in mind, though it "only" uses 24 bit by default for the output.

Thanks for the tip, though it does not seem to make a difference for ffmpeg's ac3 decoder. Usually I use eac3to as suggested by LastSilmaril because the author does keep proper bit depth conversions in mind, though it "only" uses 24 bit by default for the output.

Hmm, I tried with ffmpeg just now, and seems you are correct. Actually I was using avconv instead of ffmpeg, and it gives you different result.

Tested with the attached AC3 (encoded with intentionally high gain, and it clips when quantized to int, giving you audibly different result)sin.zip ( 8.25K )
Number of downloads: 87

[qaac] release 2.15 (refalac 2.15)posted 23 minutes ago by nu 774 [ updated a minute ago ]Fixed an awful bug of refalac of 2.xx branch. It wasn't encoding in correct frame length (4096 samples) on some cases.I noticed it when I encoded directly from lossyFLAC (not piped input), which resulted 512 samples-per-frame ALAC file. It seemed playable, but apparently is not a normal/sane ALAC file;WAV input will be fine (including piped input). Direct input from FLAC or other formats might be affected, and Re-encoding is recommended. Only refalac of 2.xx branch is affected. qaac is fine.Use more strict sharing mode when opening files. Now qaac/refalac doesn't allow other processes to open the output file when qaac/refalac is writing to it. Reading can be shared, but now qaac/refalac cannot open a file for reading when another process is writing to it.

Thanks for the tip, though it does not seem to make a difference for ffmpeg's ac3 decoder. Usually I use eac3to as suggested by LastSilmaril because the author does keep proper bit depth conversions in mind, though it "only" uses 24 bit by default for the output.

Hmm, I tried with ffmpeg just now, and seems you are correct. Actually I was using avconv instead of ffmpeg, and it gives you different result.

Tried this with latest ffmpeg binary from http://ffmpeg.zeranoe.com/builds/, and now ffmpeg can correctly output without integer clipping with -acodec pcm_f32le. The version I tried seems just too old (it was built on Nov 2012 or so, therefore it was not VERY old, but ffmpeg is really a moving target).

The refalac bug I fixed on 2.15 was because I changed source or filter layer not to repeatedly pull or generate samples until it reaches requested amount, but at the same time I didn't modified ALAC encoder to compensate the source/filter layer modification.

As a result, nobody assured ALAC encoder to process each frame per 4096 samples. Silly me!For usual cases (WAV input, with or without pipe, without DSP), source filter would read up until requested samples (=4096) anyway, so did no harm.

Tried this with latest ffmpeg binary from http://ffmpeg.zeranoe.com/builds/, and now ffmpeg can correctly output without integer clipping with -acodec pcm_f32le. The version I tried seems just too old (it was built on Nov 2012 or so, therefore it was not VERY old, but ffmpeg is really a moving target).

ffmpeg also supports pcm_f64le. Would it make any sense to use it with qaac?

If the pipe output is stored as temporary file somewhere with low diskspace, it may break... Somehow I remember that pipes under Windows can be inefficient. But I won't swear it. It may have been in times of Windows 9x.

It won't break anything or lose quality. However, native decoding format of ffmpeg (for MDCT codec) will be f32, and same for CoreAudio AAC codec. Therefore, it will simply waste time for unnecessary float<->double conversion + increased I/O size.

Will I get proper channel order for my 5.1-channel AAC file if I first decode the DTS-HD MA track to a multichannel wav file with eac3to and then encode that one with qaac? I need to decode to wav as there's sometimes clipping in the decoded output and eac3to needs a second pass to handle it.

Will I get proper channel order for my 5.1-channel AAC file if I first decode the DTS-HD MA track to a multichannel wav file with eac3to and then encode that one with qaac? I need to decode to wav as there's sometimes clipping in the decoded output and eac3to needs a second pass to handle it.

Read https://github.com/nu774/qaac/wiki/Multichannel--handling.IIRC DTS-HD MA is a 24bit lossless format, and I don't understand why you worry about clipping. If , for some reason, eac3to detects DTS-HD MA input as clipped and lower the gain, the process is not lossless, by definition.

Sorry, should have been a bit more clear. Clipping is sometimes detected when downmixing 7.1ch or 6.1ch to 5.1ch. I do that for movies that I put on my media player and put the movie with the original audio track in my archive.