title
Products            Buy            Support Forum            Professional            About            Codec Central
 

Feedback on a big dMC session

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • PCPete

    • Jul 2008
    • 8

    Feedback on a big dMC session

    I've just spent 5 days converting our wav library to HE-AAC (M4A), using dMC.

    I wanted to feed back my thoughts on the conversion publically.

    First, the good news:

    dMC correctly converted 10,341 tracks in PCM (44.1k/16-bit) WAVE format to M4A (400kbps HE-AAC) in just under 14 hours, on a quad core system running Windows XP x64. No crashes, no hangs, excellent load sharing (I worked through the conversion as normal with almost no performance penalty). That's pretty good performance - 1.12Tb of PCM files to just over 100G of HE-AAC in 14 hours with no breaks.

    And dMC successfully (!) parsed and tagged all the destination tracks in about 22 minutes.

    Even more astonishing, it converted 30+ foreign language (unicode Cyrillic, greek, arabic, swedish, and other albums and tracks) flawlessly. That's unbelievably good. dMC is the first commonly available music software that we've found that even works with unicode filenames (apart from Musicmatch Jukebox, but that must be hand-edited, and that's no longer a working product). Neither Helium nor CatTraxx is able to handle unicode tracks without significant and time-consuming hand editing.

    Now, the less good news.

    All our files are in our AUFF ("Audiography universal filename format" ):
    Code:
    \Album Artist\Album Title\Track Artist_Album Title_Track Index_Track Title.
    This naming format works perfectly (for us) for any album, artist, or track title - because of the format, they're all uniquely named. There's no possibility of duplication of names in any possible mix of files (even if they're all in the same folder, the names are always different), nor can any artist, album or title be confused with the separator characters (but it is a bit of a hassle dealing with the long filenames :().

    The problem was, some album and track titles originally contained illegal characters (question marks, colons, asterisks, and so on), and the illegal characters were replaced with underscores or hashes in the filenames. These caused big problems with the filename-to-tag 'codec' (F2T), and that took me a day to sort out.

    The F2T got really confused if there were more underscores in the filename than it expected, and using back-to-front made it even worse. Multiple unexpected underscores typically resulted in the first few underscores being "skipped", so we ended up with a lot of tracks like "The Fall Of Troy_Doppelganger" being listed as the track title instead of the artist and the album, because a 4th underscore was at the end of the filename.

    And the F2T doesn't handle 'duplicate tags' in the parse string very well. Because we have the album title in the folder structure AND in the filename, the parser got really confused if I used a tag match pattern like :
    Code:
    \[album artist]\[album]\[artist]_[album]_[track]_[title]
    because (I assume) of the duplication of information (the album title). So some tracks had 2 duplicate album tags inserted, while some had no album tags at all.

    The workaround was to skip the album artist and album name, and just use the filename to provide the tags for the parser.

    The f2t parser also doesn't work that well on wav destinations (as I found out the hard way), so I had to convert all the wav formats to M4A first, then run the parser on the "taggable" m4a files.

    I guess it would be good to see some "dummy" tag fields we could use so we can parse complex source path/files without resorting to specifying a "dummy" tag manually, which then has to be removed from all the files once the parse pass has completed.

    But apart from those minor annoyances (and the problem of codec and program folder installation that has to be done), the conversion went through extremely well.

    I know the forum's here for questions, but I did want to pass my thanks on to the developers. We'll keep using the dMC tool in the future, simply because it works so well, unlike some other tools that I could mention but won't coughSwiftcough.
  • LtData
    dBpoweramp Guru

    • May 2004
    • 8288

    #2
    Re: Feedback on a big dMC session

    If I may ask, why HE-AAC 400kbps instead of LC AAC 400kpbs? HE-AAC is designed for low bitrates but is unneeded at high-bitrates.

    Comment

    • PCPete

      • Jul 2008
      • 8

      #3
      Re: Feedback on a big dMC session

      That's a really good question...

      I'm still evaluating various lossy formats for non-unique recordings (CD rips mostly), but at each comparison, the HE-AAC codec resulted in a slight (but noticeably) better high-frequency reproduction (especially in material with a lot of HF, and minimal LF components, like some symphonic passages and some electronic music) than the LC-AAC codecs and MP3 and other lossy codecs did.

      I realise some (all? ) of this is very subjective, but listening to my tracks, on my player (Lynx L22 output, SC ULD 100W amp, JBL 3-way speakers) in my studio (and lounge!), the difference was really noticeable, even when we weren't listening specifically for differences.

      For typical commercial CD remixes (AAD or ADD), the benefit (if any) is almost negligible, but in the interests of trying to keep and use a single codec for all material, I lumped for the HE AAC for further testing.

      Also, the EBU has recommended HE-AAC for at least some programme material, and I need to be able to deal with that format in the near future. Currently most of my truly high-res material is 192k/24 PCM in RF64 or BWF format with CART chunks for metadata management. I don't have to use that format, but it does make my life a bit easier when I need to deal with conservators and broadcasters. That doesn't happen often, but it's already happened once and I don't want it to happen again! :o

      The rest of my high-res material will be converted using a lossless compression codec of some kind, but I'm having trouble finding applications that can deal with large bitrates (192/24) and large filesizes (6.8Gb is my biggest single recording). So I've still got lots of work to do.

      That's one of the best features of dMC (and Swift, I guess) - download on demand (assuming codecs are available) is such a great idea.

      Comment

      • Spoon
        Administrator
        • Apr 2002
        • 44506

        #4
        Re: Feedback on a big dMC session

        When you converted, could you not have used the original source filenames if they were named correctly?
        Spoon
        www.dbpoweramp.com

        Comment

        Working...

        ]]>