Jump to content

gottogo99

Members
  • Content Count

    32
  • Joined

  • Last visited

Posts posted by gottogo99


  1. Ok, I understand what you are getting at now. I checked my iTunes cue sheet and see that it also matches the TITLE information to the file name as opposed to the actual song title.

     

    So, ImgBurn does not read metadata from either iTunes/QuickTime or NeroAAC encoded m4a files. Any chance of reading that metadata in the future? Would be a nice feature. It does for mp3, FLAC, and ogg already.


  2. If you look properly you'll see the 'TITLE' isn't correct at all.

     

    It's just using the file name.

     

    Your m4a file must be using a tagging format that ImgBurn simply doesn't support.

     

    The reading of tags is nothing to do with DirectShow, it's all internal stuff.

    I think you are misunderstanding the bug. I have no complaints about TITLE. The bug is that PERFORMER is missing from the cue sheet for m4a files, when it is included for FLAC, mp3, and ogg files all from the same source. PERFORMER is missing for m4a files generated by me using NeroAACEnc, and for iTunes files which presumably use QuickTime. Foobar2000 shows that the PERFORMER is there for both iTunes and Nero generated files, but it isn't getting into the cue sheet as it should.


  3. It represents the exact amount of data that comes out of the directshow filter - and therefore nothing to do with ImgBurn.

     

    Lossless formats should decode to the same length as the original (fingers crossed anyway!), other formats could vary depending on the implementation within the DS filter.

    Fair enough. Any suggestions as to DS filters which give correct lengths for mp3 or m4a? So far, Orban and DSP Worx have failed for m4a and whatever Windows 7 uses has failed for mp3.


  4. Hello,

     

    I was recently testing ImgBurn with different audio file types. I noticed that the FILE-DECODED-SIZE is incorrect for m4a and mp3 files, and it differs depending on the DirectShow filter used. First, using DSP Worx for FLAC, m4a, and ogg, only FLAC and ogg have the correct length of 04:02:47. M4a is 04:02:51 and mp3 is 04:02:53:

     

    TITLE "Get Yer Ya-Ya's Out!"

    PERFORMER "The Rolling Stones"

    FILE "01. Jumpin' Jack Flash.flac" FLAC

    REM FILE-DECODED-SIZE 04:02:47

    TRACK 01 AUDIO

    TITLE "Jumpin' Jack Flash"

    PERFORMER "The Rolling Stones"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.m4a" M4A

    REM FILE-DECODED-SIZE 04:02:51

    TRACK 02 AUDIO

    TITLE "01. Jumpin' Jack Flash"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.mp3" MP3

    REM FILE-DECODED-SIZE 04:02:53

    TRACK 03 AUDIO

    TITLE "Jumpin' Jack Flash"

    PERFORMER "The Rolling Stones"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.ogg" OGG

    REM FILE-DECODED-SIZE 04:02:47

    TRACK 04 AUDIO

    TITLE "Jumpin' Jack Flash"

    PERFORMER "The Rolling Stones"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.wav" WAVE

    REM FILE-DECODED-SIZE 04:02:47

    TRACK 05 AUDIO

    TITLE "01. Jumpin' Jack Flash"

    INDEX 01 00:00:00

     

    Next, using madFLAC for FLAC, Orban for m4a, and no ogg. Now m4a and mp3 are both incorrect at 04:02:53 instead of the correct 04:02:47 for the other file types.

     

    TITLE "Get Yer Ya-Ya's Out!"

    PERFORMER "The Rolling Stones"

    FILE "01. Jumpin' Jack Flash.flac" FLAC

    REM FILE-DECODED-SIZE 04:02:47

    TRACK 01 AUDIO

    TITLE "Jumpin' Jack Flash"

    PERFORMER "The Rolling Stones"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.m4a" M4A

    REM FILE-DECODED-SIZE 04:02:53

    TRACK 02 AUDIO

    TITLE "01. Jumpin' Jack Flash"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.mp3" MP3

    REM FILE-DECODED-SIZE 04:02:53

    TRACK 03 AUDIO

    TITLE "Jumpin' Jack Flash"

    PERFORMER "The Rolling Stones"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.wav" WAVE

    REM FILE-DECODED-SIZE 04:02:47

    TRACK 04 AUDIO

    TITLE "01. Jumpin' Jack Flash"

    INDEX 01 00:00:00

     

    Not sure if the incorrect sizes are an ImgBurn bug, or a limitation of the DirectShow filters or the audio format itself. Whatever the case, the FILE-DECODED-SIZEs are wrong.

     

    PC is Windows 7, 32 bit, fully updated, ImgBurn 2.5.5.0.

     

    Thanks for your time.


  5. Hello,

     

    I recently noticed a problem when making an audio CD from files purchased from iTunes in their m4a format. When making the cue sheet, the PERFORMER information was not included. The TITLE information was correctly included. I thought maybe this was some sort of iTunes issue even though foobar2000 showed the performer correctly.

     

    I made a test. I ripped one song from a CD I own using Exact Audio Copy to FLAC and tagged it in EAC. Then I went to foobar2000 and converted the FLAC to wav, mp3, m4a, and ogg formats, using the latest version of the command line encoders (LAME, NeroAACEnc, and oggenc2). The I added each song to a cue sheet in ImgBurn. It looks like this:

     

    TITLE "Get Yer Ya-Ya's Out!"

    PERFORMER "The Rolling Stones"

    FILE "01. Jumpin' Jack Flash.flac" FLAC

    REM FILE-DECODED-SIZE 04:02:47

    TRACK 01 AUDIO

    TITLE "Jumpin' Jack Flash"

    PERFORMER "The Rolling Stones"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.m4a" M4A

    REM FILE-DECODED-SIZE 04:02:51

    TRACK 02 AUDIO

    TITLE "01. Jumpin' Jack Flash"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.mp3" MP3

    REM FILE-DECODED-SIZE 04:02:53

    TRACK 03 AUDIO

    TITLE "Jumpin' Jack Flash"

    PERFORMER "The Rolling Stones"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.ogg" OGG

    REM FILE-DECODED-SIZE 04:02:47

    TRACK 04 AUDIO

    TITLE "Jumpin' Jack Flash"

    PERFORMER "The Rolling Stones"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.wav" WAVE

    REM FILE-DECODED-SIZE 04:02:47

    TRACK 05 AUDIO

    TITLE "01. Jumpin' Jack Flash"

    INDEX 01 00:00:00

     

    As you can see, the m4a file is the only one that doesn't have the PERFORMER information. (Nothing for wave format files, I know). That was using the DSP Worx DirectShow filters for each file type. In case they were causing the problem, I uninstalled DSP Worx and installed madFLAC for FLAC and orban for m4a (nothing for ogg since I don't use it, only for this test).

     

    The new cue sheet looks like this:

     

    TITLE "Get Yer Ya-Ya's Out!"

    PERFORMER "The Rolling Stones"

    FILE "01. Jumpin' Jack Flash.flac" FLAC

    REM FILE-DECODED-SIZE 04:02:47

    TRACK 01 AUDIO

    TITLE "Jumpin' Jack Flash"

    PERFORMER "The Rolling Stones"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.m4a" M4A

    REM FILE-DECODED-SIZE 04:02:53

    TRACK 02 AUDIO

    TITLE "01. Jumpin' Jack Flash"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.mp3" MP3

    REM FILE-DECODED-SIZE 04:02:53

    TRACK 03 AUDIO

    TITLE "Jumpin' Jack Flash"

    PERFORMER "The Rolling Stones"

    INDEX 01 00:00:00

    FILE "01. Jumpin' Jack Flash.wav" WAVE

    REM FILE-DECODED-SIZE 04:02:47

    TRACK 04 AUDIO

    TITLE "01. Jumpin' Jack Flash"

    INDEX 01 00:00:00

     

    Once again the m4a format file does not have PERFORMER information. My conclusion is that ImgBurn is not reading the data correctly. Either that, or both Orban and DSP Worx have defective AAC DirectShow filters with similar bugs.

     

    PC is Windows 7, 32 bit, fully updated, ImgBurn 2.5.5.0.

     

    Thanks for your time.


  6. Any progress on this issue for the next release?

     

    In case anyone is interested, my workaround is to set the write speed one setting higher than what I actually want for burning CDRs. For example, if I want to burn at 48x, set the write speed to 52x. Obviously, the highest speed is not possible.

     

    Anyone know if this issue has been fixed for newer Samsung drives? Does it affect other brands as well?


  7. Yes, 2.5 exposes a firmware bug in the way it (the drive) handles setting the write speed for CD media using the 'SET STREAMING' command.

     

    I'm actually away on holiday at the moment and so can't test with a physical drive for a few weeks... when I can I'll see what I can do.

    Thanks. Get around to it when you can. It's an issue, but not a huge one. Maybe you'd rather not work around a "bug" that's not your fault.


  8. Thanks for looking into this.

     

    I must admit that your explanation is somewhat beyond me.

     

    I'm wondering why I got the desired speed in the old 2.4.4.0 but not now. And wondering why no problems with DVDR, only CDR and CDRW.

     

    Did 2.5.0.0 expose flaws in the firmware which were previously not detected? If so, can they somehow be bypassed? Firmware is the latest available.


  9. Ok, Discovery Mode log file is attached. This is for a CDRW, wanted 24x, got 16x due to write speed miscompare.

     

    Here's the disc info on the completed 16x burn.

     

    TSSTcorp CD/DVDW SH-S183L SB03 (ATAPI)

    Current Profile: CD-RW

     

    Disc Information:

    Status: Complete

    Erasable: Yes

    Sessions: 1

    Sectors: 182,944

    Size: 374,669,312 bytes

    Time: 40:41:19 (MM:SS:FF)

    Supported Write Speeds: 16x, 24x

     

    TOC Information:

    Session 1... (LBA: 0 - 182943)

    -> Track 01 (Mode 1, LBA: 0 - 182943)

    -> LeadOut (LBA: 182944)

     

    ATIP Information:

    Disc ID: 97m34s24f

    Manufacturer: Mitsubishi Chemical Corp.

    Start Time of LeadIn: 97m34s24f

    Last Possible Start Time of LeadOut: 74m43s00f

     

    Format Capacities:

    DT: 0x02 - NB: 182944 (0x0002CAA0) - TDP: 2048

    FT: 0x00 - NB: 275744 (0x00043520) - TDP: 2048

    FT: 0x10 - NB: 275744 (0x00043520) - TDP: 32

    FT: 0x24 - NB: 259360 (0x0003F520) - TDP: 0

     

    Performance (Write Speed):

    Descriptor 1...

    -> B0: 0x00, B1: 0x00, B2: 0x00, B3: 0x00

    -> EL: 336118 (0x000520F6)

    -> RS: 5,632 KB/s (32x) - WS: 2,816 KB/s (16x)

    Descriptor 2...

    -> B0: 0x00, B1: 0x00, B2: 0x00, B3: 0x00

    -> EL: 336118 (0x000520F6)

    -> RS: 5,632 KB/s (32x) - WS: 2,816 KB/s (16x)

    Descriptor 3...

    -> B0: 0x00, B1: 0x00, B2: 0x00, B3: 0x00

    -> EL: 336118 (0x000520F6)

    -> RS: 5,632 KB/s (32x) - WS: 4,224 KB/s (24x)

    CDRWtest.log


  10. The problem also exists using Verbatim/Mitsubishi CDRs. Write speed is one level lower than desired. In this case, I wanted to burn at 32x and the program gave me 24x, even though 32x is one of the options.

     

    ; //****************************************\\

    ; ImgBurn Version 2.5.0.0 - Log

    ; Sunday, 02 August 2009, 21:07:03

    ; \\****************************************//

    ;

    ;

    I 21:00:06 ImgBurn Version 2.5.0.0 started!

    I 21:00:06 Microsoft Windows 7 Ultimate Edition (6.1, Build 7100)

    I 21:00:06 Total Physical Memory: 1,020,280 KB - Available: 522,860 KB

    I 21:00:06 Initialising SPTI...

    I 21:00:06 Searching for SCSI / ATAPI devices...

    I 21:00:07 Found 1 DVD


  11. Thanks for the reply. I missed the other thread.

     

    I've only made a few burns with 2.5.0.0; no CDRs or DVDRs yet.

     

    I have an Intel motherboard and the SATA burner is plugged in directly. It's been that way for 20 months; never had an issue in XP or Win7 until now.


  12. Hello,

     

    I have recently updated to version 2.5.0.0 of this fine program. I frequently use it to burn CDRWs, which are Verbatims rated for 16x-24x. Using 2.4.4.0 I was able to burn at 24x but 2.5.0.0 only burns at 16x. I have 24x set as the AWS. Logs follow in case I'm doing something wrong.

     

    This log shows 24x can't be used (write speed miscompare), although 24x is one of the speed choices.

    ; //****************************************\\

    ; ImgBurn Version 2.5.0.0 - Log

    ; Saturday, 01 August 2009, 22:24:24

    ; \\****************************************//

    ;

    ;

    I 22:11:48 ImgBurn Version 2.5.0.0 started!

    I 22:11:48 Microsoft Windows 7 Ultimate Edition (6.1, Build 7100)

    I 22:11:48 Total Physical Memory: 1,020,280 KB - Available: 496,860 KB

    I 22:11:48 Initialising SPTI...

    I 22:11:48 Searching for SCSI / ATAPI devices...

    I 22:11:49 Found 1 DVD


  13. Message #12 of the FAQ is a workaround for certain mp3 audio files which decode to digital silence when using the default Microsoft mp3 DirectShow decoder. It says to find a newer version of l3codecx.ax, then unregister the old one and register the new one in its place.

     

    My suggestion is to use the widely available LAME DirectShow filter instead of the newer l3codecx.ax, which may be hard to find. Unregister the old l3codecx.ax then register the LAME DirectShow filter. Done.


  14. Update:

     

    Using RadLight, ImgBurn does tell the total time of the audio CD if it were able to burn.

     

    I tried the DC Bass .ape filter and it failed completely. Didn't give CD time. Couldn't even play the audio in Media Player Classic.

     

    My workaround was to convert everything to .FLAC and burn that. Worked fine. Fortunately I generally don't use .ape.


  15. Hello,

     

    I am trying to burn some .ape audio files. What is the recommended Direct Show filter? I am attempting to use the RadLight filter and it doesn't work. The error message is "Cannot open file... Reason: The process cannot access the file because it is being used by another process." The file is definitely not being used by another process, and the filter works for playing the audio file in Media Player Classic. Any suggestions? I'll try the DC Bass filter next.

     

    I suggest that the guide to audio CD burning list which Direct Show filters have been tested and which ones work, and which ones don't.

     

    Thanks.


  16. I can confirm that it is possible to burn gapless audio CDRs from mp3 files properly encoded by LAME.

     

    It worked using foobar2000 with its burninate plugin installed, which requires certain Nero files to be installed. Nero 6 and 7 both work, don't have 8 so don't know. Nero Lite and Micro (unofficial versions of 7) do not work as they don't have the necessary files.

     

    It would be nice if ImgBurn could be used in lieu of Nero for the burninate plugin. I realize that's far beyond the scope of ImgBurn.


  17. This is probably not the answer you're looking for but if you highlight all your mp3's in foobar2000, right click and select Convert > Convert to Album Images with Cuesheets or Chapters, and choose WAV as the output format, I believe the resulting wav file will be gapless and you can simply load the cue file it produced into ImgBurn complete with CD Text from your mp3's.

     

    (This should work with LAME encoded files that have the delay and padding information in the header.)

    Correct, that wasn't the answer I was looking for :rolleyes:. But it is a solution that would probably work (haven't tried it). I was hoping for one built into ImgBurn without converting to WAV or FLAC or anything else. Ah well, thanks anyway.


  18. Have you tried making it no gaps when making your cue sheet?

     

    Regards

    The cue sheet has no gaps. The problem is that mp3s don't always end on a CD frame boundary (1/75 of a second). The resulting tiny gap between tracks, maybe 0.01 second, is the problem. However, there is information stored in the mp3, when encoded by LAME, which somehow enables certain programs to play back without any gaps. I want to burn without gaps.


  19. You can definitely overburn in ImgBurn. I believe you can go at least 90 seconds beyond the rated time of a CDR without any trouble. Beyond that, I'm not sure. I managed almost 82 minutes on an 80 minute Verbatim made by Ritek.

     

    ReplayGain is only for playback on computers. It does nothing when burning to CD. You need a program like Nero which can modify the audio files as it burns; normalizing is what you want.

     

    Cue sheets can be edited using a text editor if necessary.


  20. I have some live albums in mp3 format. When burning these to an audio CD, there is a short but audible gap between tracks. Ideally there shouldn't be.

     

    They are encoded using LAME, which adds some type of information on padding and delay. When played back in foobar2000, there are no audible gaps between songs.

     

    I gather that if I had Nero (re)installed, I could burn the mp3s to an audio CD in foobar using its burninate plugin, and have a gapless CD. I don't want to reinstall Nero.

     

    Since ImgBurn now checks each audio file before burning, is there some way it can use the information saved by the LAME encoder to eliminate gaps when burning audio CDs from LAME mp3s? Thanks.


  21. Do you still have the file that didn't decode properly?

     

    I wonder if I might be able to detect this issue during the analysis phase so I can inform the user and save them wasting a disc.

     

    It must be certain files encoded in a certain way with a certain (possibly buggy) program.

    In my case it was 3 tracks out of 8 and I have them all if you want them.

     

    If there was some way you could detect this before burning it would be great.

×

Important Information

By using this site, you agree to our Terms of Use.