Print

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

[Garret]

I'm using Media Center 10.0.150 (registered), ripping to Ogg Vorbis. Almost every time I rip an entire album, Media Center registers all the tags in the database.

However, if I examine the files individually with ogginfo, some of the files have all the metadata tags, but random files from the album have no metadata whatsoever---not even the name! Obviously, this causes me some distress when I remove them from the database and try to import them back in: some files come in fine, but the ones with no metadata have only the name of the song (which Media Center guesses from the filename), which sometimes isn't even correct (when characters couldn't be stored in the filename).

I've noticed, though, when I rip a CD that has artwork, Media Center has to re-save all the files with the artwork (which I've specified to be saved inside each file), and thus all the files have their metadata stored correctly---apparently because of the extra step of re-writing the files.

I have two questions:

1. Is there some bug that randomly leaves metadata out of some songs ripped from an album?

2. How can I tell Media Center to go through all my files and make sure the Ogg files have metadata and if not, to store the metadata from the database? (Otherwise, I'll have to remove all the songs from the database, re-import them all, see which ones have no metadata, and then go looking for my original CDs.)

Thanks,

Garret

[JimH]

You can select files and use the tool (right click) called Library/Update Tags from Library/

[Alex B]

1. Is there some bug that randomly leaves metadata out of some songs ripped from an album?

I don't know. It doesn't happen for me.

2. How can I tell Media Center to go through all my files and make sure the Ogg files have metadata and if not, to store the metadata from the database?

You can see the actual file tag info in Action Window -> File Properties- > File Type Info.

You can update file tags by selecting the files and doing Library Tools  -> Update Tags (From Library).

Maybe you can find a common pattern if you check your files inside MC just after ripping.


Edit,

Jim was faster...

Just guessing, but could the problem have something to do with e.g. some illegal characters for APE2 tag?

[Alex B]

Do you have "Encode on-the-fly while ripping" enabled in Advanced CD Ripping Settings?. If you have, you could try to disable it.

[Garret]

You can select files and use the tool (right click) called Library/Update Tags from Library/

Thanks... now to find out why the tags are missing in the first place.

[Garret]

Do you have "Encode on-the-fly while ripping" enabled in Advanced CD Ripping Settings?. If you have, you could try to disable it.

I just tried that---one of the songs didn't get its tags updated again.

The song that wasn't updated just happened to be named "Re:Batucada" (note the illegal Windows filename character), but this shouldn't cause any problems because the filename correctly replaced ":" with "_". I went and looked at my other CDs, and some of their songs that exhibited this problem didn't have unusual characters.

Note that I've replaced Media Center's oggenc.exe with the latest version, but I doubt that has anything to do with it.

[Alex B]

Can you repeat the problem? Is it always the same if you rip the same song again? What happens if you change the original encoder back?

I have recently replaced the MP3, OGG and MPC encoders with different versions. I have not noticed any problems yet, but I usually rip to APE and do file conversations afterwards.

Replacing the build-in encoders with third party software is of course unsupported by JRiver and you do it at your own risk.

[Garret]

Can you repeat the problem? Is it always the same if you rip the same song again? What happens if you change the original encoder back?

I have recently replaced the MP3, OGG and MPC encoders with different versions. I have not noticed any problems yet, but I usually rip to APE and do file conversations afterwards.

Replacing the build-in encoders with third party software is of course unsupported by JRiver and you do it at your own risk.

I haven't tried re-ripping a CD (I have so many ahead of me to rip), but here's some more info. I just ripped a CD with no cover art, and a random song did not have its metadata updated. Then I ripped another CD that *did* have cover art on the web; this CD had *all* of the metadata stored, except the last song did not have cover art. I'm beginning to suspect some sort of lock/timing issue with Media Center.

I could try going back to the JRiver oggenc.exe, but that seems lame (pun not intended)---why should we be stuck with encoding code that's over two years old? Why does Media Center ship beta Ogg support, when the toolkit is already at 1.0.1? (I find "third party software" somewhat amusing, as the software in question is that created by the Ogg Vorbis team.)

(Again, I don't *know* if the Ogg replacement is the culprit here---I doubt it. This is just a side rant.)

Update: Now at least I know why the last image isn't saved when downloaded from the Internet. If I'm not ripping and encoding simultaneously, Media Center tries to get the image from the Internet as soon as the last file finished ripping---but before it is encoded! All the tags are re-saved after the last file is encoded, but the last file apparently doesn't get an image because the image was retrieved while it was still being encoded.

I'm guessing something similar is going on with saving the tags when there is no image.

In any case, the image downloading sequence is a reproduceable bug.

[Alex B]

I also think JRiver could update encoders more often. Media Jukebox was famous for supporting many file formats with recent encoders, but I think JRiver team has been busy with other areas recently.

I added the "third party" clause, because I don't exactly know how the tag writing is implemented with various codecs. E.g. there are also the .dll files for each encoder besides the .exes.

JRiver team should comment/fix the possible tag-writing bug. I don't see that specific problem, because I do things differently.

[JimH]

I could try going back to the JRiver oggenc.exe, but that seems lame (pun not intended)---why should we be stuck with encoding code that's over two years old?

Sometimes older software is more stable.  We try to stay behind the bleeding edge with what we include.

[Garret]

I could try going back to the JRiver oggenc.exe, but that seems lame (pun not intended)---why should we be stuck with encoding code that's over two years old?

Sometimes older software is more stable.  We try to stay behind the bleeding edge with what we include.

It turns out that my switching to oggenc.exe 1.0.1 probably is the reason for the tag update problem.

I finally went ahead and ripped a CD with the old (pre-Ogg 1.0, mid-2002) oggenc.exe that ships with Mecia Center. No missing metadata on any tracks. I erased the files and tried again with the oggenc.exe from the Ogg Vorbis 1.0.1 toolkit. Two files were missing metadata.

This isn't definitive proof that the newer oggenc.exe is causing the problem, but I did an ogginfo sweep of all my music files, and realized that several CDs I've ripped over the past few months are missing metadata on random songs. All were those ripped using oggenc.exe 1.0.1.

1. Can J River verify that this problem occurs using oggenc.exe 1.0.1?

2. Could J River fix the problem and start shipping oggenc.exe 1.0.1? I think that two years is more than enough to get past "cutting edge"---Ogg Vorbis beta code would surely seem dull by now.

This issue doesn't sound like a stability problem---it sounds more like a timing/result/notification problem, which might happen if there is an API change. There is mention of API changes here:

http://www.vorbis.com/files/1.0.1/Changelog

I would think upgrading to at least 1.0 is important. "We've also included some fundamental improvements to mid and high bitrate," according to http://www.vorbis.com/news.psp . I'm no codec expert, but two years and "fundamental improvements" make me want to switch to something newer.

For now, I'll continue using oggenc.exe 1.0.1 and then update the tags manually from the library.

If nothing else, could Media Center please start using lowercase ".ogg" extensions like everyone else instead of ".OGG"?

Thanks!

[JimH]

If nothing else, could Media Center please start using lowercase ".ogg" extensions like everyone else instead of ".OGG"?

That was fixed in MC11.  It may be fixed in a more recent version of 10.0.  I'm not sure.

11.0.12 (7/2/04)

7. Fixed: OGG encoder would capitalize its extension as "OGG" instead of "ogg".

[Garret]

That was fixed in MC11.  It may be fixed in a more recent version of 10.0.  I'm not sure.

11.0.12 (7/2/04)

7. Fixed: OGG encoder would capitalize its extension as "OGG" instead of "ogg".

Today I updated to MC11 (funny---a year to the day the OGG bug was fixed) and did an *.OGG to *.ogg rename before importing my files.

Now, before I rip any files, what about Ogg Vorbis support---my biggest concern? I note that Ogg Vorbis just hit 1.1.1:

http://lists.xiph.org/pipermail/vorbis-dev/2005-June/018105.html

What Ogg Vorbis version does MC11 now support?

Garret

[Garret]

I'm now using Media Center 11.0.309. It looks as if oggenc.exe has been updated to 1.0.1, but I'm getting worse problems than I was before.

Not only do the generated ogg files have no metadata, several .tmp files are left---even though I've specified that temp files should be removed after ripping.

And sometimes I'll shut down MC11 and try to bring it back up, but nothing happens---MC11's startup code starts running in the background and never starts up but never stops. Even shutting down the system requires me to manually kill the MC11 process.

Garret

[Alex B]

I think you have encountered a quite serious bug. The used Ogg Vorbis encoder version has nothing to do with it. As a test I ripped some CDs using the default encoder and a new beta encoder (1.1.1 aoTuVb4).

To my surprise I experienced similar problems: leftover temp files (not wave, because the sizes were identical with the ogg files) and completely missing file tags (e.g. 17 of the 20 ripped CD tracks didn't have tags).

[Alex B]

For example, I got these files when I ripped a CD using the default Ogg Vorbis encoder:


Click to see the full size image.

Only one of the ogg files has tags. The untagged files seem to have similarly sized .tmp duplicates.

Other notes:

- The log file has the name of the last track ripped. This should be e.g. [Album Artist (auto)] - [Album] instead.

- MC "downloaded" an empty cover art image (1x1 pixel jpg). The album is rare, but does MC make an empty jpg file if it can't find an image?

Media Center Registered 11.0.310 -- C:\Soft\MC\

Microsoft Windows XP 5.1 Service Pack 1 (Build 2600)
Intel Pentium 4 2861 MHz MMX / Memory: Total - 1048 MB, Free - 555 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpsp1.020828-1920) / Shlwapi.dll: 6.00.2800.1612 (xpsp2.041207-1145) / Shell32.dll: 6.00.2800.1643 (xpsp2.050311-1242) / wnaspi32.dll: 4.71 (0002) , ASPI for Win32         DLL, Copyright © 1989-2002 Adaptec, Inc. / Aspi32.sys: 4.71 (0002)

Ripping /   Drive F: HL-DT-STRW/DVD GCC-4480B  Mode:ModeSecure  Type:Auto  Speed:Max
  Digital playback: Yes /  Use YADB: Yes /  Get cover art: Yes /  Calc replay gain: Yes /  Copy volume: 32767
  Eject after ripping: Yes /  Play sound after ripping: No 

Burning /  Drive F: HL-DT-ST RW/DVD GCC-4480B   Addr: 1:0:0  Speed:24  MaxSpeed:48  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: No /  Write CD-Text: Yes
  Use playback settings: Yes /  Normalization: None

[Alex B]

Garret,

Until the bug is fixed you could rip in lossless APE format and convert the files to Ogg Vorbis afterwards. That seems to work correctly.

[Alex B]

The problem is still present. I had a reason to rip a CD in Ogg Vorbis format. I got these files:



Only the last track (#11) does not have a leftover temp file and it is the only one that contains physical file tags. The library information is correct for all tracks.

Media Center Registered 11.0.314 -- C:\Soft\MC\

Microsoft Windows XP 5.1 Service Pack 1 (Build 2600)
Intel Pentium 4 2859 MHz MMX / Memory: 1048 MB, Free - 628 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpsp1.020828-1920) / Shlwapi.dll: 6.00.2800.1692 (xpsp2.050524-1552) / Shell32.dll: 6.00.2800.1643 (xpsp2.050311-1242) / wnaspi32.dll: 4.71 (0002) , ASPI for Win32         DLL, Copyright © 1989-2002 Adaptec, Inc. / Aspi32.sys: 4.71 (0002)

Ripping /   Drive F: HL-DT-STRW/DVD GCC-4480B  Mode:ModeSecure  Type:Auto  Speed:Max
  Digital playback: Yes /  Use YADB: Yes /  Get cover art: Yes /  Calc replay gain: Yes /  Copy volume: 32767
  Eject after ripping: Yes /  Play sound after ripping: No 

Burning /  Drive F: HL-DT-ST RW/DVD GCC-4480B   Addr: 1:0:0  Speed:10  MaxSpeed:48  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: Yes
  Use playback settings: No /  Normalization: None

[NickM]

The issue of no cover art in the last file of a CD is still a problem in MC11.314.  Using the supplied APE encoder, if there is art on the web, all tracks except the last one have cover art.

In addition, I still get some files with the tags either missing or corrupted. 

I have found that turning off the Get Cover Art option fixes this.  I now manually apply the cover art to the CD using the Library Browser view ( as this selects all the files at once and it is very easy to see which CD's are missing cover art ).

nick