GNOME Bugzilla – Bug 776110
Vorbis file corrupted: "Negative or zero granulepos (-104) on Vorbis stream outside of headers"
Last modified: 2021-05-26 09:51:25 UTC
I recently used EasyTAG 2.4.3 to edit tags in an Ogg Vorbis file I had created using the usual oggenc from Xiph.org. Before editing, the file played perfectly and running ogginfo on it reports no errors. After editing, the file does not play correctly on my media players. Clementine crashes when attempting to play it. MPlayer is able to play it, but there is an audible hiccup near the beginning, and the program outputs the error "[ogg @ 0x7fb90abdf1c0]invalid pts -104" to the console. Running ogginfo on the edited file prints the following error message among the usual metadata: Negative or zero granulepos (-104) on Vorbis stream outside of headers. This file was created by a buggy encoder Since all these problems occur only after EasyTAG edited the file, I'm guessing that EasyTAG may have corrupted it. Below is the output of ogginfo, first on the original file and then on the edited file. $ ogginfo /tmp/Tubular\ Bells\ \(2009\ reissue\)/01.\ Tubular\ Bells\,\ Part\ One.ogg Processing file "/tmp/Tubular Bells (2009 reissue)/01. Tubular Bells, Part One.ogg"... New logical stream (#1, serial: 5fd64cf9): type vorbis Vorbis headers parsed for stream 1, information follows... Version: 0 Vendor: Xiph.Org libVorbis I 20150105 (⛄⛄⛄⛄) Channels: 2 Rate: 44100 Nominal bitrate: 160.000000 kb/s Upper bitrate not set Lower bitrate not set User comments section follows... CTDBDISCCONFIDENCE=653/670 CTDBTRACKCONFIDENCE=666/670 CDTOC=4+96+1C9F0+36339+3A87A+3D9BB TRACKTOTAL=4 TRACKNUMBER=1 TITLE=Tubular Bells, Part One ALBUM=Tubular Bells ARTIST=Mike Oldfield GENRE=Progressive Rock DISCTOTAL=1 DISCNUMBER=1 DATE=1973 COMMENT=Soup RELEASE DATE=2009 RELEASECOUNTRY=XE PUBLISHER=Universal UMC;Mercury Records LABELNO=0602527035055 Vorbis stream 1: Total data length: 28732050 bytes Playback length: 26m:01.093s Average bitrate: 147.240652 kb/s Logical stream 1 ended $ ogginfo Mike\ Oldfield\ -\ 01\ -\ Tubular\ Bells\ -\ Part\ One.ogg Processing file "Mike Oldfield - 01 - Tubular Bells - Part One.ogg"... New logical stream (#1, serial: 5fd64cf9): type vorbis Vorbis headers parsed for stream 1, information follows... Version: 0 Vendor: Xiph.Org libVorbis I 20150105 (⛄⛄⛄⛄) Channels: 2 Rate: 44100 Nominal bitrate: 160.000000 kb/s Upper bitrate not set Lower bitrate not set User comments section follows... TITLE=Tubular Bells - Part One ARTIST=Mike Oldfield ALBUM=Tubular Bells (2009 reissue) DISCNUMBER=01 DISCTOTAL=01 DATE=1973 TRACKNUMBER=01 TRACKTOTAL=04 GENRE=Progressive Rock Negative or zero granulepos (-104) on Vorbis stream outside of headers. This file was created by a buggy encoder Vorbis stream 1: Total data length: 28741028 bytes Playback length: 26m:01.093s Average bitrate: 147.286661 kb/s Logical stream 1 ended
The Vorbis comment code in EasyTAG does not currently support multiplexed streams, although I only discovered that after investigating this bug. As the Vorbis comment code was originally copied from vorbis-tools, it should be possible to port a multiplexing patch from there to fix the problem: https://git.xiph.org/?p=vorbis-tools.git;a=commitdiff;h=79429ee368e671bc126dc79fc51f84862b5380ca I should be able to fix that some time this week.
*** Bug 779649 has been marked as a duplicate of this bug. ***
Another problem (which also surfaces using Opus as reported in Bug 779649) is that even removing all tags with EasyTag does not repair the corrupted files, they remain unplayable. This is especially annoying if the lossless original is not readily available for re-encoding. Opus -> WAV -> Opus is not a viable option. Until the actual bug is fixed - is there any way to restore the uncorrupted file, leaving the original stream untouched (apart from a backup)? It is really distressing rendering half a library unplayable just by tagging in good faith.
(In reply to Florian Berger from comment #3) > Another problem (which also surfaces using Opus as reported in Bug 779649) > is that even removing all tags with EasyTag does not repair the corrupted > files, they remain unplayable. It is the same underlying bug. > This is especially annoying if the lossless original is not readily > available for re-encoding. Opus -> WAV -> Opus is not a viable option. > > Until the actual bug is fixed - is there any way to restore the uncorrupted > file, leaving the original stream untouched (apart from a backup)? I thought about this earlier, and I do not think so, because any metadata about the separate stream has been lost. It might be possible to guess at the stream type. > It is really distressing rendering half a library unplayable just by tagging > in good faith. Bugs are rarely intentional.
*** Bug 780055 has been marked as a duplicate of this bug. ***
I'm surprised that EasyTAG is not using libvorbis to manipulate Vorbis comments. Doing that will prevent serious bugs like this one in the future, and while it *may* not be straightforward to use, libvorbis is capable of modifying Vorbis comments as described at the bottom of the following page (section "Metadata workflow"): https://xiph.org/vorbis/doc/libvorbis/overview.html I'd very much advocate to link dynamically against the operating system's libvorbis if this approach is taken -- that way, you will automatically get any fixes and updates to libvorbis.
(In reply to Tilman Blumenbach from comment #6) > I'm surprised that EasyTAG is not using libvorbis to manipulate Vorbis > comments. > > Doing that will prevent serious bugs like this one in the future, and while > it *may* not be straightforward to use, libvorbis is capable of modifying > Vorbis comments as described at the bottom of the following page (section > "Metadata workflow"): https://xiph.org/vorbis/doc/libvorbis/overview.html > > I'd very much advocate to link dynamically against the operating system's > libvorbis if this approach is taken -- that way, you will automatically get > any fixes and updates to libvorbis. Okay, this might not be as easy as I thought it would be. Maybe copying the vorbiscomment code *is* the easiest solution after all, as error-prone as it is... :/
I don't know if EasyTag runs some tests as for a CI, but this could be a good one to do I think.
(In reply to Tilman Blumenbach from comment #6) > I'm surprised that EasyTAG is not using libvorbis to manipulate Vorbis > comments. If you would check the source code, you would find that it already does. > Doing that will prevent serious bugs like this one in the future, and while > it *may* not be straightforward to use, libvorbis is capable of modifying > Vorbis comments as described at the bottom of the following page (section > "Metadata workflow"): https://xiph.org/vorbis/doc/libvorbis/overview.html That section talks about vorbisfile, which is not featureful enough for the metadata processing that EasyTAG requires. It is currently used in EasyTAG to read the header from an Ogg file, but even that could be moved to using libvorbis directly (the current separate reading of the header and tag data is a historical oddity). > I'd very much advocate to link dynamically against the operating system's > libvorbis if this approach is taken -- that way, you will automatically get > any fixes and updates to libvorbis. This bug is nothing to do with whether EasyTAG uses libvorbis or not. It is about EasyTAG not handling multiple streams in an Ogg container. EasyTAG already dynamically links against libvorbis. (In reply to Tilman Blumenbach from comment #7) > Okay, this might not be as easy as I thought it would be. Maybe copying the > vorbiscomment code *is* the easiest solution after all, as error-prone as it > is... :/ The vorbiscomment code was directly included in EasyTAG when editing of Vorbis tags was added, hence copying the current vorbiscomment code (taking care to preserve the adaptations made to fit into the EasyTAG codebase) will fix the bug. In other words, vorbiscomment had exactly the same bug, and fixing it in EasyTAG requires a similar change (that I already linked to above). (In reply to Romain Failliot from comment #8) > I don't know if EasyTag runs some tests as for a CI, but this could be a > good one to do I think. The tagging code is currently difficult to test, and there is no infrastructure to provide some test files, but patches in this area would be very welcome.
(In reply to David King from comment #9) > The tagging code is currently difficult to test, and there is no > infrastructure to provide some test files, but patches in this area would be > very welcome. Noted ;)
(In reply to David King from comment #9) > (In reply to Tilman Blumenbach from comment #6) > > I'm surprised that EasyTAG is not using libvorbis to manipulate Vorbis > > comments. > > If you would check the source code, you would find that it already does. > > [...] > > The vorbiscomment code was directly included in EasyTAG when editing of > Vorbis tags was added, hence copying the current vorbiscomment code (taking > care to preserve the adaptations made to fit into the EasyTAG codebase) will > fix the bug. In other words, vorbiscomment had exactly the same bug, and > fixing it in EasyTAG requires a similar change (that I already linked to > above). Yes, it would seem I was too quick to comment, sorry. I didn't realize one basically would have to reimplement vorbiscomment in order to read/write tags in Ogg Vorbis files -- since that is the case, copying/adapting the code does seem like the best solution after all. Too bad vorbisfile does not support writing tags.
I think that as long as this bug exists, EasyTag should disable tag editing feature on Vorbis files and pop up a message explaining why. I'd rather not be able to edit them than figure out later that all my OGGs are corrupted and I can't do anything about it because i don't have the originals anymore.
I am not familiar with ogg internal, so I don't see why would be a single stream opus file in an ogg container "multiplexed stream", but easytag simply and reliably corrupts single stream opus files. I get the nice suggestion of "notification: Speex header too small" on the console, which maybe means "fatal error: this speex doesn't like a speex file, we have just trashed your header, sorry", I am not sure. Apart from that this bug should be retitled since it's not about vorbis, opus is trashed as well. And yes, this is extremely unpleasant right now and the least you should do is a backup and a big fat warning. As for the tests, opusinfo -q test.opus throws WARNING: Invalid packet or misplaced header in stream 1 Negative or zero granulepos (0) on Opus stream outside of headers. This file was created by a buggy encoder WARNING: Invalid packet or misplaced header in stream 1 Negative or zero granulepos (0) on Opus stream outside of headers. This file was created by a buggy encoder which may be considered a crude but pretty reliable test.
> I think that as long as this bug exists, EasyTag should disable tag > editing feature on Vorbis files and pop up a message explaining why. I'd be very much in favor of that. I spent countless hours ripping CDs to Ogg in the past weeks that wouldn't play on my SqueezeBox, and after more hours wasted trying to diagnose the problem came across this bug. Needless to say I'm not especially happy that my files were corrupted and that I'll have to re-rip everything :/ (especially since the rip which is the time consuming part was correct, but it was the tagging which corrupted them).
Hi Peter, (In reply to peter gervai from comment #13) > > Apart from that this bug should be retitled since it's not about vorbis, > opus is trashed as well. Please see Bug 779649 "easytag 2.4.3 corrupts Opus files" for the Opus part of this bug. Since the cause is the same, the developer decided to close the Opus bug as a duplicate. Please see comment #2 in the Opus bug (https://bugzilla.gnome.org/show_bug.cgi?id=779649#c2) for a script that repairs Opus files that have been corrupted by EasyTag.
*** Bug 786782 has been marked as a duplicate of this bug. ***
(In reply to Nicolas Guillaumin from comment #14) > > I think that as long as this bug exists, EasyTag should disable tag > > editing feature on Vorbis files and pop up a message explaining why. > > I'd be very much in favor of that. I spent countless hours ripping CDs to > Ogg in the past weeks that wouldn't play on my SqueezeBox, and after more > hours wasted trying to diagnose the problem came across this bug. > > Needless to say I'm not especially happy that my files were corrupted and > that I'll have to re-rip everything :/ (especially since the rip which is > the time consuming part was correct, but it was the tagging which corrupted > them). I support these comments in the strongest terms. I don't know the protocol for these things, so apologies in advance if I cross some line in saying this, but it seems to me that the 'importance' of this bug should be set at something other than 'normal normal' given that it irreversibly corrupts files.
(In reply to Andrew from comment #17) > > it seems to me that the 'importance' of this bug should be set > at something other than 'normal normal' given that it > irreversibly corrupts files. +1 In my mind, this is a blocker. The more, as this bug corrupts Opus files as well (Bug 779649).
This might be the same bug. I noticed it just now after ripping at least ten CDs since the bug first appeared. The rips from those CDs are not corrupted at all. The corruption I noticed is a click and repeat of the first second of each track. The rips were all done with abcde(1) which uses cdparanoia to rip, oggenc to encode, and mid3v2 to tag. Maybe there's something special about the CD from which the rips get corrupted. The ones in question for me are the two from Devo's "EZ Listening Muzak".
More strangeness. I used Picard to add a tag to an Ogg. Then I went back to Easytag and added more tags. Now Easytag won't corrupt that file.
Hi This bug just corrupted 1 week of tagging work on my library :-( I am using debian and it seems that version 2.2.4-1 in jessie did not have that bug. It would be useful to know: - which was the last version without this bug - under which conditions an off file (how do I check for them?) triggers this bug - how a corrupt file can be repaired (even partially) - what the rough timeline would be for a fix Until then, I hope I can revert to an older version Thanks Tom
As for the conditions under which a file gets corrupted, I am quite confused. I have seen easyTag corrupt only some of the songs of an album even though all songs were encoded using the same software and the tags written with easyTag were very similar. See the following example where the first song got corrupted and the second didn't: $ ogginfo 01_Movimento_Perpétuo.ogg Processing file "01_Movimento_Perpétuo.ogg"... New logical stream (#1, serial: 4f817009): type vorbis Vorbis headers parsed for stream 1, information follows... Version: 0 Vendor: Xiph.Org libVorbis I 20050304 (1.1.1) Channels: 2 Rate: 44100 Nominal bitrate: 128.000000 kb/s Upper bitrate: 4294967.295000 kb/s Lower bitrate: 4294967.295000 kb/s User comments section follows... TITLE=Movimento Perpétuo ARTIST=Carlos Paredes ALBUM=Movimento Perpétuo DATE=2003 TRACKNUMBER=01 TRACKTOTAL=11 GENRE=Other Vorbis stream 1: Total data length: 1618901 bytes Playback length: 1m:26.120s Average bitrate: 150.385601 kb/s Logical stream 1 ended $ ogginfo 02_Variações_Em_Ré_Menor.ogg Processing file "02_Variações_Em_Ré_Menor.ogg"... New logical stream (#1, serial: 001b757f): type vorbis Vorbis headers parsed for stream 1, information follows... Version: 0 Vendor: Xiph.Org libVorbis I 20050304 (1.1.1) Channels: 2 Rate: 44100 Nominal bitrate: 128.000000 kb/s Upper bitrate: 4294967.295000 kb/s Lower bitrate: 4294967.295000 kb/s User comments section follows... TITLE=Variações Em Ré Menor ARTIST=Carlos Paredes ALBUM=Movimento Perpétuo DATE=2003 TRACKNUMBER=02 TRACKTOTAL=11 GENRE=Other Vorbis stream 1: Total data length: 3929478 bytes Playback length: 3m:23.400s Average bitrate: 154.551740 kb/s Logical stream 1 ended
*** Bug 789309 has been marked as a duplicate of this bug. ***
Found out quite a few of my opus files are affected by this. Please introduce a big red warning message for ogg containers.
Ok, so any plans to attack this bug? Is there still development being done on this project? Is easytag being abandoned in favor of gnome-music?
Downstream report for openSUSE: <https://bugzilla.novell.com/show_bug.cgi?id=1069789>
Ah, thanks Tristan. Unfortunately, v2.4.2 still shows the bug for me. For the record I built 2.4.2 using all libraries current to Fedora 26.
Hello, I reproduce this bug with 2.4.3 version on debian. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855251
I corrupted a number of ogg files in my music library a week or so ago, and ran across this bug report in the process of troubleshooting. If anyone is still interested, there are a couple of shell scripts that will recursively check your music library for Easytag-corrupted ogg files, and fix them. The scripts are available at https://trackitweb.com/fix-ogg-files-corrupted-by-easytag/
Unfortunately, re-encoding an Ogg Vorbis file is still a lossy process. This is not a clean fix :(
Reverting this commit fixed the error for me: commit https://git.gnome.org/browse/easytag/commit/?id=e5c640ca3f259f1b74e716723345521987a7bd68
I can confirm that reverting e5c640ca3f259f1b74e716723345521987a7bd68 does fix this bug. When vcedit_open returned originally (before the above commit), it left the input stream position after the headers had been read. When vcedit_write was called, it continued reading the rest of the data from the input stream. After the above commit, vcedit_write reopens the file and therefore incorrectly starts reading data from the very start of the file. vcedit_write needs to skip over the headers before reading packets.
(In reply to Tristan Miller from comment #26) > Downstream report for openSUSE: > <https://bugzilla.novell.com/show_bug.cgi?id=1069789> This bug has (hopefully) been fixed downstream in openSUSE: <https://build.opensuse.org/request/show/596947>
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/easytag/-/issues/ Thank you for your understanding and your help.