I am ripping a CD to MP3 192kbit/s CBR. However, the <Bitrate> tag produces "141" in the filename!?!
Environment is Win XP SP2.
Strange problem using <Bitrate> when ripping CDs
Moderator: Gurus
Strange problem using <Bitrate> when ripping CDs
I use the <bitrate> tag when ripping CDs (or rather I would like to do this). However, as you can see from the screen shot below there seems to be a bug in handling it.
I am ripping a CD to MP3 192kbit/s CBR. However, the <Bitrate> tag produces "141" in the filename!?!
Environment is Win XP SP2.
I am ripping a CD to MP3 192kbit/s CBR. However, the <Bitrate> tag produces "141" in the filename!?!
Environment is Win XP SP2.
Sounds like its taking the bitrate from the CD (1411kb if I'm correct) but has it truncated into 3 characters as mp3's etc don't have bitrates over a 1000.
For now you might want to organize files afterwards using the bitrate.
For now you might want to organize files afterwards using the bitrate.
Download MediaMonkey | License
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
I'm not sure if this can be fixed. MM uses the bitrate of track before conversion and for that reason you see that value. It could possibly use the bitrate track will have after conversion, but e.g. for Variable Bitrate MM doesn't know this value exactly until the track is fully converted.
As Lowlander suggested, you can use Auto-organize after the tracks are converted.
Jiri
As Lowlander suggested, you can use Auto-organize after the tracks are converted.
Jiri
Well you could create the file (and as such the location) after the file has been fully created (ie rip to a temp location). This would solve the bitrate problem.
Otherwise you might want to consider to take the bitrate tag out of the dialog as it's useless (Aren't all CD's at 1411k?? and it even isn't able to handle 4 characters).
Another benefit of a temp location would be that if something fails (windows, MM) you wouldn't have a corrupt/bad file in the library (not sure if that could happen).
Otherwise you might want to consider to take the bitrate tag out of the dialog as it's useless (Aren't all CD's at 1411k?? and it even isn't able to handle 4 characters).
Another benefit of a temp location would be that if something fails (windows, MM) you wouldn't have a corrupt/bad file in the library (not sure if that could happen).
Download MediaMonkey | License
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
-
Guest
Well at least I know what's up now!
Still, 141 is wrong by just about any definition.
Lowlander's solution would be the delux option. A quick fix would be to use the encoded bit rate for CBR files and just substitute a string like "VBR" for VBR files. Then CBR files would be right, and you would still get a useful indication for VBR files.
Thanks for the info anyway.
Still, 141 is wrong by just about any definition.
Lowlander's solution would be the delux option. A quick fix would be to use the encoded bit rate for CBR files and just substitute a string like "VBR" for VBR files. Then CBR files would be right, and you would still get a useful indication for VBR files.
Thanks for the info anyway.