Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jb82]

Seems rather silly raising issues right now but for whatever it matters...

QAAC (MP4) external coder is working fine for device sync EXCEPT that maybe 1-2 in 1000 files does not get embedded cover art added properly - resyncing the affected files solves this (e.g. nothing wrong with source or the encode process it's just that sometimes it's breaking and it seems to be to do with the embedded cover art process).

This results in some players being unable to play the audio, whilst others seem to ignore it - for example, foobar shows the attached error for the cover art, but plays the audio ok. MC plays the audio (but obviously doesn't display cover art)

I tried using built-in mp3 and after several thousand files haven't seen the same issue - so maybe it's a race condition or something when calling an external encoder?

I will try Nero AAC to see if it's the same.

Can provide comparison files if it helps (e.g. a perfectly encoded file vs the same file with the issue).

Best wishes to all.

[jb82]

FWIW, just thought I'd share a few findings on this...

So it seems that this issue is probably when using simultaneous conversions/external encoder/covert art: add to tags. I'm guessing a multi-thread/race condition to do with the process of embedding cover art.

If I set simultaneous conversions=1 it all works perfectly. Quite easy to recreate - setup encoding with external encoder, simultaneous conversions >1, enable the add cover art to tags option (source files that are being sync'd use Folder.jpg rather than embedded) and try encoding, say, 1000 files or so. Chances are good that a proportion of the encoded files will be missing cover art and may not play on some devices/software. I should point out - as far as I tested - the audio conversion itself is fine - the problem is with the tag.

Obvious workaround is to encode with 1 simultaneous conversion, although that obviously slows things down considerably! Maybe this could be investigated as a bug?

______________

Totally unrelated to MC, but may be of interest to some people...

- I discovered that Apples qaac encoder is non-deterministic for certain audio files (very small proportion - 1% or less). I've seen one reference to this (https://github.com/lordmulder/LameXP/issues/53) but no concrete explanation as to why. Race condition is about the only thing I could find (note - not to be confused with the MC issue above! :-) but I don't think qaac is multi-threaded by default. Is it likely this has a big effect on the audio quality?? I've not really tested further. I highly doubt it does, but an alternative explanation is that the encoder is buggy and at that point anything's possible...

- I decided to try the nero AAC encoder. This does appear to be deterministic, so no ambiguity as opposed to qaac. Furthermore, a quite nice, albeit VERY basic, objective test of lossy encoders is to run multiple spaced tones through them and see the impact to transients. Nero and qaac are virtually identical at 192 kb/s CBR. At 224 kb/s nero is somewhat cleaner than qaac. The (many plausible :-) arguments aside about the validity of this comparison, I decided to switch to nero at 224 kb/s and have done with it!

- dBPoweramp has issues. I was using it as a comparison point for the MC nero aac encodes (also using foobar, bit compare utility to so the audio comparison). Whilst MC appears to be completely reliable (at least based on ~24k conversions :-), maybe 0.5-1% of dBP conversions had issues and these were NOT flagged by dBP as conversion errors. However, they definitely were errors. Re-encoding the affected files led to bit identical conversion with MC. To be fair, I was using multi-core/threads with dBP so maybe dBP has a multi-threaded issue that impacts the audio conversion.
______________________